> Date: Thu, 27 May 2010 22:04:51 -0400 > From: Robert Connolly <rob...@linuxfromscratch.org>
> The reboot is needed for the new capabilities module (which is now built in > non-optional in recent kernels), and the extended attribute options for the > filesystem. Almost all distributions enable all these kernel modules, so > rebooting chapter 6 is probably not necessary for most of us. This could be > added to host system dependencies, instead of adding a reboot to chapter 6. IMHO, the reboot also helps validate the correctness of the toolchain and ensures independence from the original system. This brings back up the point of a HLFS live build. I've started to "betatest" a bootable (via http://linux-live.org/ scripts) .iso of my personal HLFS system. I don't know how much work it'll be to do for the 1.0 release, but a fully self-building/hosting HLFS-live .iso would be a terrific milestone to aim for (but cross-purpose to my stated preference of a sooner 1.0 release) > An old idea was to take the LFS stable book (LFS-6.6 for example) and modify > it. I think this would simplify a lot of things. HLFS would be patches on the > LFS book and packages. My assumption was that this is how HLFS got started, but maybe you (Robert Connolly) can give is a bit of history on that and how well it worked (or didn't) > larger, but this can be worried about when it becomes a problem. With this > system, the HLFS stable book would release shortly after each LFS stable > release. My guess (and it's only a guess) is that simply keeping the HLFS sources up-to-date with vendor/3rd party security patches would be plenty enough work already for a small group. I aloud if fully forking off from vanilla LFS would be a better idea. -dean takemori -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
