Keeping track of programs

Question

When I install a simple program it often uses make && make install and doesn't often even have an uninstall target.

If I wish to upgrade a program, is it standard protocol to assume it just rewrites seamlessly over the old program?

How do I keep track of these programs; do most people just 'fire and forget' and if no uninstall target is given do I have to manually delete everything?

Answer 1

Install each program in a dedicated directory tree, and use Stow or XStow to make all the programs appear in a common hierarchy. Stow creates symbolic links from the program-specific directory to a common tree.

In more detail, pick a toplevel directory, for example /usr/local/stow. Install each program under /usr/local/stow/PROGRAM_NAME. For example, arrange for its executables to be installed in /usr/local/stow/PROGRAM_NAME/bin, its man pages in /usr/local/stow/man/man1 and so on. If the program uses autoconf, then run ./configure --prefix /usr/local/stow/PROGRAM_NAME. After you've run make install, run stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

And now you'll have symbolic links like these:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

You can easily keep track of what programs you have installed by listing the contents of the stow directory, and you always know what program a file belongs to because it's a symbolic link to a location under that program's directory. Uninstall a program by running stow -D PROGRAM_NAME then deleting the program's directory. You can make a program temporarily unavailable by running stow -D PROGRAM_NAME (run stow PROGRAM_NAME to make it available again).

If you want to be able to quickly switch between different versions of the same program, use /usr/local/stow/PROGRAM_NAME-VERSION as the program directory. To upgrade from version 3 to version 4, install version 4, then run stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Older versions of Stow doesn't go very far beyond the basics I've described in this answer. Newer versions, as well as XStow (which hasn't been maintained lately) have more advanced features, like the ability to ignore certain files, better cope with existing symlinks outside the stow directory (such as man -> share/man), handle some conflicts automatically (when two programs provide the same file), etc.

If you don't have or don't want to use root access, you can pick a directory under your home directory, e.g. ~/software/stow. In this case, add ~/software/bin to your PATH. If man doesn't automatically find man pages, add ~/software/man to your MANPATH. Add ~/software/info to your INFOPATH, ~/software/lib/python to your PYTHONPATH, and so on as applicable.

Answer 2

You can use checkinstall to create a package (RPM, Deb, or Slackware compatible packages) That way, you can use your distros package manager to add/remove the application (but not update)

You use checkinstall in place of the make install command (using the -D parameter for Deb; -R is RPM and -S is Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall will build and install the package by default, or you can have it only build the package without installing.

checkinstall is available in most distros repositories.

Answer 3

For the most part this was the reason behind packages, ports, and other types of managers to prevent this type of thing from happening.

I would say that manual deletion is the only way for a manual install, unless someone else has a better answer to that point I may not be aware of.

Answer 4

One more alternative is from the Linux From Scratch hints:

More Control and Package Management using Package Users

3 Package Users
3.1 Introduction

The basic idea of this scheme is easily explained. Every package belongs to a certain "package user". When you install a package, you build and install the package as this package user, causing all files that are installed to be owned by the package user. As a consequence all the usual package management tasks can be comfortably achieved through the use of standard command line utilities. A simple ls -l <file> will tell you, for instance, what package <file> belongs to and a find -user ... command allows you to perform an operation on all the files belonging to a certain package, e.g. delete them to uninstall the package.

But package management is not all that package users are good for. Because package users do not have root-rights, the installation of a package is limited in what it can do. One thing that a package user is not allowed to do, for example, is to overwrite files from a different package user. Clashes between different packages that want to install a binary, library or header file of the same name are more common than you might think. With package users you never run the risk of package B's installation destroying files from package A silently without you noticing. Every attempt of doing this during package B's installation will cause a "Permission denied" or "Operation not permitted" error so that you have the chance of taking appropriate steps. Another thing that package users are not allowed to do is install setuid root binaries. The decision to make a binary setuid root is also something that a prudent admin does not want to leave up to the creator of a software package.

Usually package user accounts have no valid password so that only root can su to a package user, which ensures that package users do not open an additional way into the system and undermine security. But you may set passwords anyway to allow a co-admin who you want to be able to install and maintain certain software packages to do so without having access to the actual root account. This co-admin could for instance install, delete, change additional libraries which might be necessary for his workgroup. He would be unable, though, to remove or modify libraries which don't belong to him/her, such as libc.

After this first crude suggestion, I found an evolved variant:

crablfs -- User Based Package Management System

This crablfs is the latest specimen of package management using unique uids and gids for package management, but on sourceforge it is evolving again in ulfs:

uLFS: Your Manageable and Reusable Linux From Scratch

For causal users of installed packages I think that "package users" LFS solution is a light one, less invasive and elegant. In short, you install packages in /usr/local or /home/user/local and track files using unique uids and gids for each package but put all files in the traditional places, common directories /usr/local/bin, /usr/local/lib like it is in all mainstream Linux distributions ... file occlusion and unwanted file overwriting or deleting is avoided by a neat Linux trick explained by Matthias S. Benkmann in more_control_and_pkg_man.txt which need only normal file and directories permission manipulation, for example the sticky bit permission for directories to avoid unwanted file overwrites:

3.3 Groups

Every package user belongs to at least 2 groups. One of these groups is the "install" group, which all package users (and only package users) belong to. All directories that packages are allowed to install stuff in belong to the install group. This includes directories such as /bin and /usr/bin but excludes directories like /root or /. The directories owned by the install group are always group-writable. This would be enough for the package management aspects, but without further preparation this would not give added security or control because every package could replace the files from a different package (the change would be visible in the output from ls -l, though). For this reason all install directories get the sticky attribute. This allows users to create new files and delete or modify their own files in the directory, but files from other users can not be modified or removed. In the rest of this hint, whenever the term "install directory" is used, it refers to a directory that belongs to group install, is group-writable and sticky. IOW, to turn <dir> into an install directory you would do

chgrp install && chmod g+w,o+t

For me it looks like a simple and clever solution! I used this scheme in my LFS build and it is a working solution ...

Answer 5

1. You can make an empty RPM as a reminder.
2. You can look into wrapping the software properly into an RPM.
3. You can leave a copy of the tar files from the install in /usr/src/non-rpms to remind you (that's what I usually do).