Danie Roux

People person, change agent. Journeyer through problem and solution space. Interested in being interested.

Danie Roux header image 2

Using GNU Stow to manage source installs

August 7th, 2005 · 1 Comment · general

Installing packages from source used to be the only way to get software onto your Linux box. SLS was the first real Linux distribution, but I believe Slackware was the first to offer package management, with Debian to offer the first package management with dependency resolution.

Since then, source installs became a problem. Installing your own version of a package over the version provided by the distribution often leads to something breaking.

Luckily, the Filesystem Hierarchy Standard makes provision for this, by specifying that your own source installs should go into /usr/local.

Most software that uses GNU Automake installs into /usr/local by default. The questions you should be asking are:

  • How can I be sure that the software does not trample over anything already installed by overwriting something?
  • How do I keep multiple versions of software installed?
  • How do I manage (add, safely delete) the software I install into /usr/local?

I discovered GNU Stow years ago. It was written specifically as an answer to all those questions. It comes standard with most distributions, there’s even a package for Fedora1 .

I am still surprised that I don’t see many people advocating it. That may be because the manual is big and people are too lazy these days to read through it. Hopefully if you finish reading this you’ll know how to use Stow and understand why you would want to.

In a nutshell: Stow has its own directory, /usr/local/stow. You install all the software into that directory. You then invoke Stow, which makes symlinks into the /usr/local hierarchy. That’s all Stow does. It never copies or removes files. It only deals in symlinks.

So, you can compile and install all your software without using root priviliges. Only when invoking Stow do you need to become root. The advantage of this is the answer to the first question: Since you are installing the software into /usr/local/stow as a normal user, you can be sure that no files are placed anywhere else, nor are any of your system files changed.

Installing software with Stow:

For example, lets install a package called fubar:

In the source directory, as a normal user, run:

./configure --prefix=/usr/local
make PREFIX=/usr/local # Only some Makefiles need this2
make install prefix=/usr/local/stow/fubar

Then, become root, usually using the command su.

Now you need to do this:

cd /usr/local/stow
stow fubar

And that’s it. For the rest of the system it will look as if fubar was installed directly into /usr/local. In reality, it was installed into /usr/local/stow/fubar, so you know exactly what was added to your system.

Uninstalling software with Stow:

Well, you can’t. Stow doesn’t ever delete any files. Ever. It only makes and deletes links. You can thus delete all the links to the package and you do this using:

cd /usr/local/stow
stow --delete fubar

The rest of the system won’t see fubar anymore. Deleting /usr/local/stow/fubar will completely remove it from your system.

This leads us to the next great feature of Stow:

Keeping multiple, self-compiled versions of a package around

Since GNU Stow doesn’t remove any files and since they will link anything in the /usr/local/stow hierarchy into /usr/local, you can keep more than one version around.

Let’s say there’s a fubar-1.0 that you installed. Now you want to install the CVS version to test it out3. This is how you would do it:

In the directory where you have the CVS source code, do the same as when you installed fubar. Just change the make install to:

make install prefix=/usr/local/stow/fubar_cvs

Now, unlink the fubar-1.0:

cd /usr/local/stow
stow --delete fubar

Then, Stow the CVS version:

stow fubar_cvs

You can easily switch between these two using only Stow. So if the CVS version is a bit too bleeding edge, its easy to fall back to stable.

1 This is a bit of a jab at the poor people that have not yet converted to
the greatest distribution of them all.

2 This is a convention found in many Makefiles. the VARIABLE=VALUE on the command line is how you can change the value of a variable in that Makefile.

3 These days you hopefully get a Subversion repository instead.

Tags: ··

1 response so far ↓

Leave a Comment