hlfs-dev Digest, Vol 1127, Issue 1

Robert Connolly robert at linuxfromscratch.org
Sat May 29 23:16:39 PDT 2010


On Saturday May 29 2010 10:43:19 pm Dean Takemori wrote:
> > 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.

Yes. Glibc's test suite depends on the host kernel.

> 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)

From the beginning HLFS fell out of sync with LFS. Updates to the book, xml, 
build procedures, package versions, etc, were not updated regularly. In 
retrospect this wasn't a good thing because it caused more work for us.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20100530/28956cce/attachment.sig>


More information about the hlfs-dev mailing list