jeroen at linuxfromscratch.org
Thu May 13 02:57:35 PDT 2004
Jeremy Utley said the following on 13-05-2004 04:13:
> Jeroen Coumans wrote:
>> 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).
Well, isn't that "just" a technical issue? From what I know about
Subversion, it can easily handle coherent changesets.
>> 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.
We should have an IRC->mail gateway... :-)
Seriously, not everyone is able to participate in IRC discussions
because of different timezones. If you find it productive we could set
up regular meetings though and post logs or summaries to the list.
But the disadvantage of IRC is that unless you've been there, there is
no way to know what was being discussed, except if logs are posted
somewhere. Perhaps it would be a good idea to use an IRC logger ->
website, similar to how the mailing list is archived?
Different communication tools have different advantages/disadvantages...
> 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'm not arguing about the technical merit, but the speed and
requirements for moving from unstable to testing. Speed: how about 2
weeks of cooking in unstable? Requirements: blessing of the unstable
editors and full LFS build by someone from the testing team? Toolchain
changes require a part of BLFS too - at least one of kde, gnome, java,
> 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.
Ok, seems as my above requirements are already met.
> 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.
> I don't know if I'd ever say hotplug is REQUIRED at all. If you compile
The way I understood udev, it uses hotplug for discovery of devices and
adding them to /dev. I don't know if it requires the hotplug package
itself for it, though it certainly seems to require a /sbin/hotplug present.
"udev works entirely in userspace, using /sbin/hotplug calls that the
kernel makes whenever a device is added or removed from the kernel."
More information about the lfs-dev