On Fri, 2012-01-13 at 16:27 +0000, Matt Burgess wrote: > 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).
http://lists.busybox.net/pipermail/buildroot/2009-September/029433.html states this requirement for Expat was because dbus-glib requires it to be built against Expat. http://lists.busybox.net/pipermail/buildroot/2011-June/043629.html states that dbus-glib now works against the libxml2 backend as well, so that dependency can be dropped. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
