My plans

Jeremy Utley jeremy at
Wed May 12 19:13:18 PDT 2004

Jeroen Coumans wrote:

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

But, the way CVS works, when we make the branch, we take HEAD as it 
exists at a certain tagged point, and branch at that point.  You can't 
take GCC 3.4 (which was imported into HEAD after nptl/udev), and branch, 
without taking all the things that came before it (or at least not easily).

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

Already have been, in personal conversations regarding these issues with 
Matt - we've talked a LOT about these issues on IRC - personally, I wish 
more of the development staff would use IRC as a tool as well, as it 
makes it much easier to discuss this type of thing (You don't have to 
sit there and wait for a response) - the hardest part is having everyone 
together.  BE-LFS moved fast because the three of us
who worked on it were there together on IRC to discuss things.

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

Yes, I can agree on that - but for a LOT of people, it's already working 
quite well.  My systems here at home are strictly 2.6/nptl/udev systems, 
as are a lot of other people now, mostly thanks to the BE-LFS book.  I 
doubt a lot of people would be there without 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.

Not really - the branch for LFS-6 to move to testing could be made at 
ANY time after the release of 5.1.  We have a stable set of packages, 
and pretty good instructions that seem to work well for most
people - the only real lack in testing is that we don't have non-x86 
arch's to test on yet.

> 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 

I'll admit, I haven't looked at what you've done there - personally, I 
tend to avoid Wiki pages like the plague.  But I will take a look and 
see what you've got there.

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

I don't know if I'd ever say hotplug is REQUIRED at all.  If you compile 
support for all your hardware (including removable devices) into the 
kernel, with no modules, you probably wouldn't need it (someone
else who knows more than me would have to address that).  But, for what 
I would consider to be a "State of the Art" linux system, I think we 
should include hotplug support into the book.  It seems to be the 
preferred method for dealing with modules at this point, and it 
CERTAINLY makes things easier.


More information about the lfs-dev mailing list