My plans

Jeroen Coumans jeroen at linuxfromscratch.org
Wed May 12 18:52:32 PDT 2004


Jeremy Utley said the following on 13-05-2004 01:53:
>>
> 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.

See my reply to Zack. Unstable is meant as test ground, sandbox. Stable 
things from unstable should move to testing. A release only means a 
branch point from the testing branch. Nothing about testing or unstable 
is affected by a release. That was the whole point of moving to this 
development model, after all: continued development in unstable, 
relatively stable but up-to-date CVS, and slightly outdated but very 
stable release.

> 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.

I'd very much like to enforce it. My "guiding principles" were meant 
precisely for doing that: to remove unneeded cruft and to justify the 
existence of left-over packages. It has the advantage of being 
relatively objective, thus would remove the need for debate over 
inclusion/exclusion of packages. Plus it was more or less fitted to the 
current packages.

I can understand your point of view, even though I don't necessarily 
agree with it. But can we then work on a set of rules which cover your 
idea of a basic LFS system, using my principles as a basis? I find it 
hard to come up with good rules though; see my efforts in the Wiki. Feel 
free to add/edit/remove/comment!

> 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'd like to keep it in unstable and perhaps testing. We've never done 
anything like this before; to promote a new way of doing old things 
(managing devices) so I'm very hesistant to start with it now. It could 
be very educational, as you say, but I'd first like to see it work in 
unstable and testing. Can we agree on that?

> 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.

Technically, it doesn't change much and I agree it should be in the book 
when it's needed. I agree on the "State of the art" thing and certainly 
technical excellence should always be the goal. But the discussion is 
currently pointless since LFS-6.0 is still a long way.

So, in anticipation of that, let's now focus on establishing ojbective 
ground rules for the LFS package mix so we don't have to discuss it ever 
again (for the sake of the community! :-) ). Join me on 
http://wiki.linuxfromscratch.org/index.php?pagename=WhatPackagesInLFS

> 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.

Also don't forget about hotplug, which becomes mandatory as soon as udev 
is required.

-- 
Groeten/Greetings,
Jeroen Coumans
{faq,website}@linuxfromscratch.org
www.jeroencoumans.nl



More information about the lfs-dev mailing list