My plans

Jeremy Utley jeremy at
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 mailing list