HLFS project scope. (robert baker)
robertmbaker at gmail.com
Wed May 26 12:59:42 PDT 2010
Find my comments in-line with yours.
On Wed, May 26, 2010 at 2:14 PM, Dean Takemori <deant at hawaii.rr.com> wrote:
>> 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?
No. I mean the HLFS system it's self. That statement was more or less
the goal of the HLFS-1.0 release in a nut shell.
>> 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
The official package list should closely mirror current stable LFS
>> - 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.
I agree this has been an issue in the past. It would make me cringe to
see suggestions for package version bumps in most cases as well.
However there is very little needed to bump package versions to the
LFS level, and most of the work is already done. There are just a
couple of changes to be made in the temporary tools and the rest will
follow quickly. I will be making updates to SVN shortly with the work
I have been doing so you all can get a better idea of just how close
For the record I am only suggesting bumps to reach the package level
of the current stable LFS.
>> - 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.
That has not been my experience. I have built grub-1.97.2 with little
effort and no additional packages. I even managed to build it for
booting temporary without difficulty.
As an aside, I have been going back over the need for a bootable
temporary system. All things considered capabilities can be set after
the reboot into the final system and that was the major reason to make
>> - fortify source by default
>> - test suite/sanity checks
> Probably the third biggest TODO: determining which tests return
> false negatives, which ones are critical etc.
There are very few test failures when you run the tests using the
vanilla specs w/ -fno-stack-protector -fno-PIE
I have some more work to do in this area but suffice it to say the
failures are minimal, and documenting them when we have a final test
procedure will be trivial.
>> - 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?
In my opinion it is arguable either way. If we arrive at a general
consensus that we should focus on one architecture then we can push
64bit to version 2.0. I will say that if we build a multilib 64bit
system that there isn't a whole lot of additional effort involved.
Pure64 isn't a huge effort, but it is more work than multilib.
>> - libcap-ng (requires python)
> I would vote no on this; Is there a compelling reason to use
> it rather than libcap for v1.0?
The most compelling reason for it is that it is an actively maintained
project. Second to that it is easier to use than the traditional
libcap because it has a more comprehensive toolset.
> -dean takemori
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
More information about the hlfs-dev