Software Packaging (was Re: Scope?)

ashes cendres at
Tue Dec 30 19:59:32 PST 2003

I agree hlfs should not ship with rpm, or pretty much any other package 
manager, leaving that as an option to the admin. But, rpm, portage, and 
others are able to use a non-privleged user for automated builds; and I do 
feel the base hlfs system should setup a model for this user. Something 
similiar to role based access control, for restrictions on memory and 
filesystem use (so if glibc goes in an infinite loop and uses 500 megs of 
swap, it doesn't have the unlimited permissions (ulimits) of root).
Something like this, its not written in stone:

su - lfs && ./configure && make
exit or sudo chroot (sudo is due for a summers day exploit)
chroot /tools /bin/su - lfs
make DESTDIR=/usr/local install
Here we can use mtree, or something similiar, to do a full tree checksum of 
every newly installed file. If we run mtree on / (in chroot) after make 
install it will show us anything new in /etc, and anything that was 
overwritten (libiberty.h).
If we do lndir /usr/local/bin /tools/usr/local/bin (and lib/) as user lfs 
before chroot, and do configure && make in chroot, we would get a permission 
denied if make install tries to overwrite anything.
tar jcf package.tbz2 /usr/local
The mtree file can be appended to the tarball if it helps. The mtree output 
files can be used by /etc/daily to verify almost every file on the system, if 
you have a powerout and one file is currupted, you'll know. And its imposible 
to acciedentaly install an suid program without doing chmod manualy. And the 
mtree file can be used for deinstall scripts.

This is an unautomated package system yet is still very powerfull and can be 
intergrated with 3rd party package systems. For this reason I think its 
suitable for hlfs. It would teach what package managers are supposed to do.

More information about the hlfs-dev mailing list