Testing branch proposal
conathan at conet.dyndns.org
Sun Jul 4 22:01:05 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
> 2) NPTL
> 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.
I saw some potential in hotplug [once I finally found the scripts to
dissect]. I dont know enough information on them to make a verdict now.
[I admit, going completely modular or completely built in seems a bit
harsh to me, and not entirely sure moving to/from hotplug warrants either
change]. I admit to not knowing all the issues we have with this package,
except for a race condition where the device may not be created in time
for it's use.
As the bootscripts themselves stand, hotplug silently exits if
/sbin/hotplug is not found [I dont know if I approve of that, but *shrug*,
it works]. I'd rather have it moved back to contrib, and have the
lfs-bootscripts follow testing though. in the hotplug stop script, we
disable any further hotplug events from being generated, that will have to
be moved somewhere else since we register udev[send?] as a handler.
More information about the lfs-dev