hlfs-dev Digest, Vol 1127, Issue 1

Dean Takemori 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 
> 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

More information about the hlfs-dev mailing list