HLFS project scope

robert baker robertmbaker at gmail.com
Tue Jun 15 11:10:20 PDT 2010

Sorry for the delay in replying.

On Sat, May 29, 2010 at 9:27 PM, Dean Takemori <deant at hawaii.rr.com> wrote:
> 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

With a few exceptions this should be very practical. The vast majority
of the hardening we do is in the form of setting more strict defaults
in gcc. Where staying in line with LFS is impractical we can easily
choose package versions that fit our needs. A good example is the
kernel. We have to use a kernel that the grsec patches apply to.
> 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.

Something like that is now, and in my opinion should remain out of the
project scope.

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

Since it looks like we will be patching LFS XML rather than doing a
full rewrite I would consider it fair to rely on their 64bit support
work rather than push for anything more or less.

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

I think that is a fair concern. Robert Connolly and I have discussed
libcap vs libcap-ng a little. For now we will stick with libcap. I may
take some time to look into this for later revisions though.


> -dean takemori
> --
> http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

More information about the hlfs-dev mailing list