releases and stuff

Robert Connolly robert at linuxfromscratch.org
Sun Nov 21 00:13:29 PST 2004


On November 21, 2004 02:03 am, Archaic wrote:
> On Fri, Nov 19, 2004 at 07:33:43PM -0500, Robert Connolly wrote:
> > Either install autoconf and automake in chapter 5, or (my favorite)
> > preconfigure all the sources in advance and don't delete them.
>
> How much excess disk space is the latter going to require?

I'll have to tell you later, probably in the GB or less ballpark :\ it might 
just squeak on one 700MB cdrom.

> > On an unrelated topic, the only thing I don't like about the
> > more_control hint is that packages are installed to the real system.
> > You don't know what or where files will be installed in advance.
>
> I must say I've never really understood your concern for installing
> packages directly. They are just as easily removed from the "real"
> system as they would be from the destdir. This just avoids the extra
> step of a destdir. Besides, anyone installing from source on a live
> server without knowing explicitly before hand what a package installs
> seems a bit shaky. Even being able to compile on a server incorporates
> more attack paths than I would want to explore.

Not everyone has more than one computer. I think anything installed to / 
should stay there, not 'make install' and clean up after, treating / like 
obj/. Maybe I am rationalizing my personal taste and this is not important to 
others. Maybe this is a distro-like feature. I feel this should be a 
standard, beit almost impossible to maintain in Linux. Another idea is to run 
install(3) by hand, and don't use 'make install' at all, this is feasable 
without Glibc.

> > Maybe a --with-sysroot macro is what we need for packages that don't
> > already have it.
>
> When we get to the point that we are patching a large number of packages
> to conform them to a minor personal preference to how things should be
> done, we are getting away from writing a book and heading towards being
> s specific distro. IMO, patching should be kept to a bare minimum to
> cover FHS guildlines, fixing compilation problems, and closing security
> holes.

I feel we're a bit handicapped when trying to keep everything generic. I'm not 
proposing patching for things we won't use or need, or patching for things 
that have nothing to do with security; but I don't want things like 'LFS 
doesn't do it that way' or 'thats unsupported' to hold us back.

I have to let my personal choices come threw or else I wouldn't get anything 
done. I'm prepared to reverse anything I do if it turns out to be wrong, or 
if there's a better way.

robert




More information about the hlfs-dev mailing list