unstable branch for LFS

Matthew Gibbons matthew at brightspark.eurobell.co.uk
Tue Oct 15 05:26:07 PDT 2002


Another way to achieve this is to leave the unstable LFS on the HEAD branch,
and create branches for stable release. These can then be maintained
independently if necessary.

I think the KDE project uses a similar approach.

Cheers,
Matthew

"Matthias Benkmann" <matthias at winterdrache.de> wrote in message
news:20021015141530.0265e90f.matthias at winterdrache.de...
> 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
>


-- 
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