Re: [Gnu-arch-users] solving problems where your wheel is the squeekiest

[Jeremy Shaw]

On Nov 01, 2005 09:12 PM, Thomas Lord <address@hidden> wrote:

> Why the f do people put up with crap like that ("sometimes the
> build process will patch [source] files")? 

Mostly, because of the huge number of source packages we have 
to deal with in a very small period of time, with only a handful
of human resources. If you have only a few hours to download, 
import, modify, build, and QA a package, you aren't about to
start a long discussion with debian and the upstream maintainers
as to why they do not do things differently. Especially if all
you really want to do is make k3b 'depend' on cdrecord instead
of a mere suggests. [Note: I don't think k3b modifies the source
during build. However, it is written in C++, which is just as
bad ;) ]

>  > 'make clean && tla commit && make' 
> 
>  > Can take a very long time (hours) for something like x.org or OOo.
> 
> Isn't that something to beef to x.org and OOo about?  How does their
> first-year-student-fundamentals bogosity warp into a design
> requirement
> for revision control?  What are the relative potential labor costs,
> here, of fixing their problems vs. implementing the work-around in
> ancillary tools?  And who's paying?

Well, the specific issue with x.org is that we modify debian's
packaging.
The debian x maintainers use quilt to maintain a set of patches against
the upstream x.org.

If you are unfamiliar with quilt you can read:

"How To Survive With Many Patches Introduction to Quilt"

available at: http://www.suse.de/~agruen/quilt.pdf

quilt is not a revision control system, but rather, a tool for 
maintaining a set of patches against a moving upstream target.
Debian maintains their copy of x.org + quilt patches in svn.

When you build the debian package, the first thing it does is apply
all the debian patches to the upstream source tree, and then build 
the source. For the debian maintainers, this system is actually not
too bad -- it allows them to fairly easily maintain a bunch of small 
patches which can be easily added, removed, or updated, and which
have descriptive patch names.

This type of problem is not limited to just one or two packages either,
stuff like this happens *all the time* when trying to patch debian's 
packages. 

So, I think the choices are:

 (1) get thousands of developers and hundreds of debian maintainers to
     agree on a good system for doing things (the social solution)

 (2) Try to develop tools to deal with the existing mess 
    (the technical solution)

So far we have had greater success with (2). Of course, we do not really
want a bunch of Linspire specific tools, and we would like to see a
more unified system of collaboration. This is why we try to use and
improve existing tools (like tla), and why we are members of efforts
like the DCC.

It is my opinion that if we do a good job with (2), making the tools
more powerful and flexible, we will have an easier time at (1).

j.