HLFS project scope

Dean Takemori deant at hawaii.rr.com
Sat May 29 19:27:02 PDT 2010

> Date: Wed, 26 May 2010 14:59:42 -0500
> From: robert baker <robertmbaker at gmail.com>
> The official package list should closely mirror current stable LFS
> where possible.

> For the record I am only suggesting bumps to reach the package level
> of the current stable LFS.

I agree that at some arbitrary "starting" point that this
should be true, but I wonder how practical it will be in the
long run to keep the package versions closely synced with LFS

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

Sorry, I like a bigger console than 80x24, so I experimented with
trying to build everything needed from scratch (freetype and fonts) to 
get that working (never quite got it working).  You're right, a 
minimal grub-2 isn't too difficult.

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

My opinion is that it's preferable to get whatever v1.0 is 
out sooner rather than later, but if you've already done most 
of the work to get multilib 64-bit working, then maybe it's not 
a big deal.

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

My concern is the addition of python as a prerequisite as libcap/libcap_ng
needs to be built fairly early on I believe.

-dean takemori

More information about the hlfs-dev mailing list