Software Packaging (was Re: Scope?)
cendres at videotron.ca
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
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