On Thu, 2012-01-12 at 15:32 -0600, Bruce Dubbs wrote: > LFS now provides a good, solid, and relatively simple way of bringing up > a single system. It does not directly support any of these more complex > methods. The question is: should LFS add these capabilities? > > If we did decide to implement the capability for an initramfs and/or > systemd, I think we might need a whole new chapter in the book. > > One of the major purposes of LFS is to explain how the packages in Linux > fit together. > > Personally, I have mixed feelings. For a lot of situations, our current > implementation of LFS/BLFS works very well. For a large implementation > where the requirements are varied and complex, I don't think LFS will > ever be preferable over a commercial distro. > > For the purposes of explanation, what we have works, but if we don't > change, it will become farther and farther away from what people see in > other implementations.
Indeed, and for this reason I think we need to give serious consideration to where upstream are heading. I think an initramfs implementation is the right way to go to have people be able to build their systems so they match more closely what they would find in regular distros. I don't think it would be fair on our readers to teach them how to put together a system that is too unlike any regular distro they could encounter. I like the idea behind systemd, inasmuch as they are trying to speed booting up by using dependencies to allow scripts to run in parallel rather than Sysvinit's serial boot ordering. I realise that on pared down LFS systems bootup is pretty quick anyway, but even so, it just feels like the right way of doing things to me. I must add though, that I'm not particularly fond of their plans for a binary system logger, although I also admit to not having seen its output so I don't know whether its just the UUIDs that are binary or whether all log messages are also binary. I like being able to use standard UNIX text processing tools (less, more, awk, grep, etc.) on log files for obvious reasons! According to Fedora's spec file, the only additional dependency it would bring in is DBus and that would in turn bring in Expat (aside: I've no idea why DBus prefers Expat; I'd much rather use libxml2 as it seems to be the more widely used library, and having 2 XML parsing libraries just seems daft). Udev's requirement for kmod is the easiest one to tackle by the looks of things, and your implementation plan of putting it alongside module-init-tools until such time as its command line tools are on a par with m-i-t's is a good one. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
