A Suggestion For A Simple Package Manager

DJ Lucas dj at linuxfromscratch.org
Wed Mar 18 16:44:38 PDT 2009

Frank Peters wrote:

> Yes, that is correct.  The install commands are specified
> in the Makefiles for a package.  If it would be possible
> to redirect output from these commands to a text file, that
> certainly would be a lot simpler than the approach taken
> by package managers such as installwatch or CheckInstall,
> which use libraries to intercept certain kernel system
> calls.

Well then the author needs to manually add those commands to the auto 
tool scripts.  Got a standard in mind?  For working with existing 
scripts, you could do something similar to the following and achieve 
your goal:

mv /usr/bin/install /usr/bin/install.orig &&
cat > /usr/bin/install << "EOF" &&
# Begin install wrapper

/usr/bin/install.orig $@ > $HOME/install.log
# End install wrapper
chmod 755 /usr/bin/install

Unfortunately, you'd need to do the same with cp, ln, mkdir, mknod, mv, 
rename, rm, etc.  Suddenly, the approach by installwatch, CheckInstall, 
and other like approaches, makes quite a bit more sense.

Additionally, there is a reason that the vast majority of makefiles 
today support DESTDIR.  The following is what I (and others) have 
proposed several times for the book.  We simply install to the DESTDIR 
for all packages, and then manually install the package from the 
DESTDIR.  If you want to tar up the DESTDIR for binary packages, then go 
for it.  The install commands that you'll need to give to your favorite 
PM's install and post-install scripts are provided (complete) by the 
book's instructions at that point.

In this manor, we've managed to explain the complexities of PM, give 
real examples, and still avoid using any particular PM by default. 
Dependencies are already covered by the book, the only thing left is 
upgrading.  Concerning upgrades, Perl (specifically perldoc) is the only 
catalog type file that I didn't cover in my suggested instructions 
(posted a couple of months ago) that would be of even remote interest in 
LFS.  A couple of others have already taken this approach as well and 
might even already have that one covered, I haven't taken the time to 
look at others' docs/scripts yet.  Now BLFS is tens of times more 
interesting (read complicated), but it could get there with a little effort.

-- DJ Lucas

More information about the lfs-support mailing list