Tree of HLFS base?

Jason Stevens jastev at
Sat Jan 7 22:31:33 PST 2006

Kevin Day wrote:
>>Does anyone have a tree of all files installed as part of the HLFS
> Pretty simple trick here (aside from the major libraries/programs, which
> may need tweaks) Just...

Yup.  I know *how* to do it, I just don't have a system on which to run 
it.  At the rate at which I'm compiling (based on available time, 
mostly), it'll be a few days.

>>Also, if anyone has a recommendation for a particularly good
>>reference towards building really minimal systems
> This is something I have been tossing around for some time.  What is a
> minimal system?
> So here is my definition: It boots.  That's it!
> uClibc/glibc, some shell: ash, bash, possibly non-interactive (or at
> least not fully interactive) shells such as tcsh (sysvinit or similar
> for a more friendly boot)

I agree, after inference from the above.  It's not enough that the 
system boots, you also need (I assert) root to be able to log in, which 
implies a shell and perhaps a few other things (perhaps a home dir for 
root, with perhaps a .bash_profile in it, etc).

>>From there, you figure out what you want to do with that system.  Get
> those files, and only those files.  Then fullfill their dependencies.
> And that would be my definition of a useful minimal system.
> You also mention not using compilers/interpreters.  You can build all
> of your final compilers for building your system in some other
> location. (say /usr/toolchain under my systems)  There you can still
> use the system libraries or remove them at little costs.  Every need a
> new package, just put your backed up compilers there, compile, and then
> remove them.

Yeah, that's pretty much what I'm doing.  My final vision is to have 
several really stripped-down HLFS systems, each running a small set of 
related services (ie, one running qmail, imapd, etc, a different one for 
httpd perhaps), each in it's own VMware vm.

To get there, I'm building the stock HLFS system, which I'll use as a 
template.  The trick is knowing which of that stuff needs to move over 
to the stripped down systems.  I know how to do that for the services 
(ie, qmail), but I'm less confident that I know which of the bae HLFS 
material needs to move over.

For example, I really don't want a compiler in any of the vm's that are 
providing externally visible services.  Don't need 'em there, and it 
adds risk.  The same (generally) for Perl.  Make doesn't seem 
"dangerous", but why have it if you don't need it?  Etc.

It seems that I can get pretty close to "eyeballing it", by reading the 
comments in the HLFS install pages and judicious use of ldd.  Also, 
there seems to be some useful content (a little wheat among much chaff) 
in the Linux Standard Base specs.  But I hate to resort to trial and 
error for what should be deducible from "first principles".

There are several anecdotes and a HOWTO or two on the subject, I'll slog 
through them and see if there isn't some better way already published.


More information about the hlfs-dev mailing list