hlfs-dev Digest, Vol 1127, Issue 1
deant at hawaii.rr.com
Sat May 29 19:43:19 PDT 2010
> Date: Thu, 27 May 2010 22:04:51 -0400
> From: Robert Connolly <robert at 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
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.
More information about the hlfs-dev