On Sun, Apr 30, 2006 at 09:29:16AM +0100, Matt Darcy wrote: > > 1.) Kernel Headers, yes you knew this was coming but its certainly worth > talking about, a lots been said on this but its really still unclear of > direction. I suppose the discussion should center around
For LFS-6.2, I recommend patching in inotify and then moving trunk to Jim's script. This is the course of action I am working on in my sandbox. > 2.) Udev - This again has been a hot topic of many projects, but with > LFS now dropping hotplug I feel it important ti discuss and clear up a > few areas Again, here's what I'm working on: A rules file that is not minimal WRT creating properly named devices, but is minimal in terms of configuration if the device cannot be reasonably used with a stock LFS build. Also, the rules will generally be x86-only. To keep things coordinated amongst the projects, we really should be utilizing a more modular ruleset. I envision a common ruleset that covers all devices that are common across all arches, then additional rules files for the different arch-specific devices. Obviously, LFS will x86-centric. CLFS can then use our common rules file and extend it modularly with arch-specific devices. And BLFS can show people how to configure the group and perms (if the device requires BLFS). > 3.) users and group creation, I'm reluctant to touch on this again as I > know its close to a few individuals hearts and a lot of time has been > put into this, but due to the ude discussion I think its worth at least > touching upon. If BLFS does the udev configuration, then it creates the group/user. If it is a device that is usable by the base system, then the base book configures it. A disk is usable, so group disk stays. floppy and cdrom are reasonable groups, and their devices are usable in a base system, so I think they should stay, too. Audio and video groups, however, aren't needed. Depending on how one looks at things, we have either 99, 499, or 999 UID/GID's free for system users and groups. I don't see why it should be difficult to come to an arrangement. Let the base books provide a base setup and let the extended book provide the extended setup. However, I do agree that if a system is in place, and cannot be proven to be faulty, then that system should be the base upon which future decisions are made. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
