Testing branch proposal

Jeremy Utley jeremy at jutley.org
Sun Jul 4 22:53:40 PDT 2004

Greetings, dev readers!

Now that GCC 3.4.1 has been released, the time I believe has come to
consider cutting LFS to a testing branch.  However, the question is,
what to bring with us to the testing branch.  Here's the new things
we're looking at for the new LFS 6.0 testing branch, from what I can

1) Kernel 2.6
3) Newer Glibc version
4) GCC 3.4.x
5) Udev
6) Hotplug

And here's the issues, as I see them:

1) Kernel 2.6 (and associated utilites):  No-brainer IMHO...they're well
tested, and should Definately be included in this release
2) NPTL: Small issue in that LFS 5.1.1 unmodified can not build this,
nor can a lot of released distros - however, kernel upgrading is a
relatively painless thing, and the issues that arise becuase of adding
NPTL are minimal (few problems with packages that link to berkeley-DB). 
I think this should be a go as well.
3) Newer Glibc: Initial rough testing indicates that our current 0701
Glibc tarball is pretty good - it's also pulled from about 10 minutes
prior to a massive breakage in glibc that exists to this day (So much
for glibc always being stable).  Ryan can hopefully iron that out while
we're in testing, with his expansive array of test hardware.
4) GCC 3.4.1: This will cause some issues for BLFS, as it *DOES*
increase strictness over 3.3.x - however, MOST of the issues are already
worked out, and patches are in the patches project.
5) Udev:  This is one of the sticky ones....My opinion is well known -
to prepare for the future, we need to get started with udev - and it
works pretty well.  I would say keep this one, perhaps with a mention on
the page where we deal with devices that if you desired, you could still
at this time use make_devices as in previous versions of LFS.

Now for the thorny part:

6) Hotplug:  After seeing all the discussions on the issue of hotplug
support in the kernel, I'm re-thinking my position on it.  It has it's
uses, but in many circumstances, it's still a little raw.  I think for
the purposes of 6.0, perhaps we should leave it out (which was our
original plan for LFS 6.0 at the time of the restructuring, in fact).

So, my proposal is this:

Cut a testing branch, and pull hotplug, and anything else we've done
related to it.  Stabilize, and call that LFS 6.0.  Meanwhile, the
development team can continue to attempt to work out the issues with
hotplug, perhaps having one of us interact with the upstream maintainer
regarding the concerns we have.

To some of you who have "interacted" with me on this issue, this might
come as somewhat of a shock that I would suggest this.  But, considering
the situation, I think this might be the best solution for the time
being - perhaps trying to add both udev and hotplug at the same time was
too much at once.



More information about the lfs-dev mailing list