HLFS project scope. (robert baker)
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>
> <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?
More information about the hlfs-dev