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
> 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
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
> 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
> 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
More information about the lfs-dev