Testing branch proposal
matthew at linuxfromscratch.org
Tue Jul 6 13:23:57 PDT 2004
On Sun, 04 Jul 2004 22:53:40 -0700
Jeremy Utley <jeremy at jutley.org> wrote:
> 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
7) readline addition
8) ed removal
9) iproute2 swapped in for net-tools
10) procinfo removal
<aside>Please, if you know of any other differences that I've missed
then feel free to add them here!</aside>
1, 2, 3, 4, 5, 9, 10) Yes
6) No - it's got too many issues for it to be able to stabilise in time.
We have the 'createfiles' and 'modules' scripts to cater for devices
not handled by udev and for those wishing (or forced) to use modular
kernels. Additionally, a lot of the discussions and development of the
hotplug related functionality would appear, from an outsider, to be
geared towards supporting a distro-like setup where nearly everything is
detected and handled automatically. I still think LFS needs to get
its users to *think* about what hardware they have in their system and
how to configure/support it properly. Yes, we could get all hardware
detected & modules loaded automatically and *teach* people how it's
done, but I think that's going too far away from LFS' educational goals.
7) I'm still not sure about this (despite me posting a definitive
message just a few minutes ago). We'll pull it into testing for the
time being, but don't be surprised if it gets booted out a little later
on. There is value to be had in reusing code. It's statically compiled
into bash, so there'll be a separate copy in RAM for every bash process
(yes, we're probably talking marginal amounts, but it's exactly this
that .so files were designed to negate). iproute2 will also use it.
e2fsprogs also uses it, although it loads it via a dlopen() call so it's
not a compile-time dependency.
8) If the BLFS crew agree with taking on its maintenance then I'm happy
to see this leave. It's not required by anything in our build process,
and is such an infrequently used tool (nowadays) that I believe it's
rightful place is in BLFS.
I'll create the testing branch this weekend, so you have until then to
comment on the above, but it's unlikely that my stance will change
unless very strong technical or educational arguments are presented!
More information about the lfs-dev