unstable branch for LFS

Matthias Benkmann matthias at winterdrache.de
Tue Oct 15 05:15:30 PDT 2002


I think with all the changes going on right now with gcc-3.3 and
glibc-2.3.1 and other unstable packages that will become part of a future
LFS version (e.g. coreutils) we need an unstable branch of the LFS book.
The current CVS version cannot fulfill this function as it should improve
upon LFS 4.0 (leading to a better 4.1) instead of getting lots of unstable
changes using packages whose introduction to stable LFS lies in an
uncertain future.

Without an unstable LFS branch, it will be hard to keep track of the
solutions people are working out right now. For instance there have been
several proposals for solving the libnss segfault issue and several
reports/patches to fix gcc-3.3 issues, but the introduction of the new
glibc and gcc to the stable LFS book is probably months away and when it
comes, we will have to dig through the archives to find the solutions that
are in front of our noses now.
And putting new patches into CVS to accomodate a gcc the book doesn't use
can introduce instability into the CVS version (which as I said should
only become more stable and better). And putting unreleased packages such
as gcc 3.3 into CVS is out of the question anyway.

I believe an unstable version of the book would be a very good thing. I
don't know what kind of check in rules exist now for the editors but for
the unstable book they should be very relaxed. If someone mails a patch to
the list to fix a gcc 3.3 issue an LFS book editor should just be able to
commit it to the unstable version with no more than a casual glance. If it
breaks something it can always be fixed later when someone reports the
breakage. 
Unreleased packages, snapshots and CVS versions of packages should be okay
and in fact preferred to stable+patch in the unstable book. There should
be no pressure for the unstable book to work at all times or to contain
the best solution at all times. For instance when I came up with the
s/libn/FOOB/ sed to work around the segfault problem it should just have
been commited to the unstable book even though it's a horrible hack. Now
that better solutions have been presented (the invalid nsswitch.conf, and
the s/LD_LIBRARY_PATH/LD_LIBERRY_PATH/ sed) it should be discussed which
one is preferable and that one should go in the unstable book.

I'd like to emphasize that the unstable book is not intended to ever
become stable. That's what the current CVS version is for. Changes will be
copied from unstable LFS to CVS LFS when the appropriate time has come
(e.g. when gcc 3.3 is released and put into LFS CVS, the gcc 3.3 patches
will be copied from unstable to CVS).

MSB

p.s.: In case someone is confused: Of course the unstable book will also
be in the CVS repository. But when I say "CVS version" in the above text
I'm referring to what is currently called the CVS version. This
terminology would of course have to be changed into "stable branch" and
"unstable branch" or something like that.

-- 
The early bird gets the worm, but the second mouse gets the cheese.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list