jeremy at jutley.org
Wed May 12 16:53:48 PDT 2004
Jeroen Coumans wrote:
> Jeremy Utley said the following on 12-05-2004 20:19:
>> Matthew gave the go-ahead for udev/nptl/2.6 a LONG time ago - it's
>> already in CVS, in the b6_0 head, ready to become testing
>> when the time comes.
> It seems you're right: I found three messages in which Matthew talked
> about inclusion of udev, last one from may 9th; little after his
> appointment of second man. Seems I've lost this battle then! ;-)
> What happened to the proposed guiding principles though; Matthew was
> willing to use them as a basis for justification of the package set.
> Do I understand correctly that it's not in the testing branch yet?
> When will it be included in testing - when it's declared stable, or
> when it becomes a kernel requirement (when static devices are
> deprecated)? My preference obviously would be the latter...
Testing branch is currently 5.1 still, until release. 2.6/udev/nptl is
currently slated for LFS 6, as part of the import of the work we did in
BE-LFS. So once the 6.0 branch is moved to testing, is when
udev goes as well.
Honestly, the big problem I have with the current minimalist approach is
the fact that, despite what is said, it's never at all been enforced on
the book. Otherwise, autotools and procinfo would be in the book.
Ed's there because Patch can utilize it in rare cases (very old
patches). Procinfo is useless, IMHO, and autotools, while nice, are
certainly not needed for a base LFS install to reproduce itself. We've
since added readline to HEAD for a similar reason, Bash and e2fsprogs
can utilize it to provide additional functionality (in the case of
e2fsprogs) or to allow for modularity (in the case of bash using
external readline rather than internal).
Should we stick with things until we're forced to do them because of
changes elsewhere, or should we plan for the future by getting them in
while they are still optional? My vote is for the latter, the
educational aspect is served by informing the user of this new
functionality that's available.
I've always considered LFS to strive to build a "State of the art" linux
system, using where possible, the most up to date packages and
techniques available to us. When you really think about it, we're not truly
changing that much....removing make_devices and adding udev - just a
different method of creating devices (dynamically instead of static).
Otherwise, the build remains essentially the same.
Just some things to think about, I know a lot of you won't agree with
me, but from a developers point of view, as well as a users point of
view, I think the incorporation of Udev is a GOOD THING.
More information about the lfs-dev