HLFS project scope. (robert baker)

Dean Takemori deant at hawaii.rr.com
Wed May 26 12:14:40 PDT 2010

> Date: Tue, 25 May 2010 18:18:33 -0500
> From: robert baker <robertmbaker at gmail.com>
> Subject: HLFS project scope.
> To: Hardened LFS Development List <hlfs-dev at linuxfromscratch.org>
> Message-ID:
> 	<AANLkTinmBwmFSUk5OjHd-6peJcQV9n6zDLmZQ9PjRjK- at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> Below you will find my suggestions for the scope of the HLFS book.
> What we want to provide.
> - A base platform and build environment

I'm assuming you mean a replacement for the LFS-Live .iso 
specifically meant for HLFS builds?  

> Work needed to reach a release candidate

- I think the biggest TODO: is to establish the "official"
package list (with major-version number) and the build order

> - various package version bumps

From experience, this is a constantly moving target, a
freeze on major version numbers for certain targets would
have to be a early milestone.

> - grub2

A little bit tricky.  A full build-from-scratch requires 
building freetype for the font.  Despite having done work
to do it for my own builds, I would vote to save this for
(say) v1.2 since there's plenty of work to do already.

> - fortify source by default
> - test suite/sanity checks

Probably the third biggest TODO: determining which tests return
false negatives, which ones are critical etc.

> - x86_64 and i?86 build completion
> - multi-lib or pure64 or both
> - if pure64 is included patches or additional seds are needed

How important is a 64-bit build to v1.0?  Might it be better
to focus on a single target (x86) and then work on the 64
bit version for (say) v1.2?

> - libcap-ng (requires python)

I would vote no on this;  Is there a compelling reason to use
it rather than libcap for v1.0?

-dean takemori

More information about the hlfs-dev mailing list