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?

  • 6
    Is GNU Stow an option here? "GNU Stow is a program for managing the installation of software packages, keeping them separate (/usr/local/stow/emacs vs. /usr/local/stow/perl, for example) while making them appear to be installed in the same place (/usr/local)." Commented Jul 10, 2011 at 2:05
  • @Mike it looks very promising; I like the idea of enabling and disabling versions of programs seamlessly. Firstly how active and stable is the program and how often does a program break the prefix protocol?
    – Will03uk
    Commented Jul 10, 2011 at 2:17
  • 1
    Ridiculously stable (1.3.2 dates to 1996, and 1.3.3 to 2002), and almost totally inactive. It's just a Perl script that manages symlinks. Way back in the day, it was a pain to get compilers and such bootstrapped into stow, but for end-user applications, it's been fine. I've used it for any application I couldn't easily backport from newer Debian releases, or get from one of the Solaris package repositories. Commented Jul 10, 2011 at 14:34

5 Answers 5


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
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.

  • 5
    I believe things may have changed a bit since the time when this answer was posted. So just as an update: GNU Stow currently supports ignore lists, multiple stow directories, conflict pre-detection, etc. I also think that stow is under active development while Xstow has not been updated for ~3 years. Commented Apr 21, 2013 at 21:54

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.

  • This is good but I'm mainly using tarballs for very active programs which arnt often packaged and the ability of switching between broken and not versions in stow is great
    – Will03uk
    Commented Jul 13, 2011 at 22:34
  • Unfortunately, checkinstall seems to be not that actively maintained (?) :-( Commented Apr 29, 2013 at 13:11
  • @NikosAlexandris I'm curious, if it works for its intended purpose and does this well - which, as a current non-user, I'm assuming it does - why is it necessary that it be actively maintained? Commented Feb 6, 2018 at 2:00
  • @Hashim I see your point. Out of "habitual thinking", though, would a piece of software related to compile software, not need maintenance, when compilers evolve? Commented Feb 7, 2018 at 10:47

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.


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 ...

  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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .