Re: PATCH [0/3]: Simplify the kernel build by removing perl.

[Rob Landley <rob@landley.net>]

On Saturday 03 January 2009 18:37:12 Leon Woestenberg wrote:
> Hello,
>
> On Sun, Jan 4, 2009 at 12:03 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> Dependencies very quickly become dependency hell. If A requires B,
> >> then A also inherits all (future) requirements of B, etc. etc.
> >>
> >> In my daily software development work with Linux and GNU software in
> >> general, 10% of it is spent fighting/removing these extremely "thin"
> >> or false depencies, so that it is usuable in embedded devices.
> >
> > First of all, I largely consider this a joke.  All real-life embedded
> > kernel builds take place on hosted platforms; anything else seems to be
> > done "just because it can be done", as a kind of show-off art project.
> > Cute, but hardly worth impeding the rest of the kernel community for.
>
> Let me explain why it is not a joke for me, although yes I agree it's
> a funny way of how software engineering works.
>
> My argument on thin dependencies indeed mostly holds for run-time
> dependencies (to reduce size) but also for build dependency (to reduce
> complexity)*.

I usually just point to the gnucash 1.6 release as where this sort of thing 
leads if you ignore it long enough:
http://lwn.net/2001/0614/

These days, a more modern example is the way that after even the gentoo folks 
gave up on trying to build openoffice (and shipped prebuilt binaries of it in 
their "build everything from source code" OS), Open Office's own developers 
described that project "profoundly sick" and "stagnating" ( 
http://developers.slashdot.org/article.pl?sid=08/12/28/0124230 ).

Neither project _started_ with an inbred development community that presented 
a brick wall to new developers.  Complexity grew because they didn't fight 
against it, and because they didn't have good rules by which they could say 
"no" to any.

Environmental dependencies in your build environment are a cost, and as with 
all costs it's ok if you get enough in return for it.  The Linux kernel has 
historically been extremely lean in this regard, and discarding that strength 
should at the very least come with commensurate concrete benefits.

Rob