Stow is a tool for managing the installation of multiple software packages in the same run-time directory tree. One historical difficulty of this task has been the need to administer, upgrade, install, and remove files in independent packages without confusing them with other files sharing the same filesystem space. For instance, it is common to install Perl and Emacs in /usr/local. When one does so, one winds up (as of Perl 4.036 and Emacs 19.22) with the following files in /usr/local/man/man1: a2p.1; ctags.1; emacs.1; etags.1; h2ph.1; perl.1; and s2p.1. Now suppose it's time to uninstall Perl. Which man pages get removed? Obviously perl.1 is one of them, but it should not be the administrator's responsibility to memorize the ownership of individual files by separate packages.
The approach used by Stow is to install each package into its own tree, then use symbolic links to make it appear as though the files are installed in the common tree. Administration can be performed in the package's private tree in isolation from clutter from other packages. Stow can then be used to update the symbolic links. The structure of each private tree should reflect the desired structure in the common tree; i.e. (in the typical case) there should be a bin directory containing executables, a man/man1 directory containing section 1 man pages, and so on.
Stow was inspired by Carnegie Mellon's Depot program, but is substantially simpler and safer. Whereas Depot required database files to keep things in sync, Stow stores no extra state between runs, so there's no danger (as there was in Depot) of mangling directories when file hierarchies don't match the database. Also unlike Depot, Stow will never delete any files, directories, or links that appear in a Stow directory (e.g., /usr/local/stow/emacs), so it's always possible to rebuild the target tree (e.g., /usr/local).
A ``target directory'' is the root of a tree in which one or more packages wish to appear to be installed. A common, but by no means the only such location is /usr/local. The examples in this manual page will use /usr/local as the target directory.
A ``stow directory'' is the root of a tree containing separate packages in private subtrees. When Stow runs, it uses the current directory as the default stow directory. The examples in this manual page will use /usr/local/stow as the stow directory, so that individual packages will be, for example, /usr/local/stow/perl and /usr/local/stow/emacs.
An ``installation image'' is the layout of files and directories required by a package, relative to the target directory. Thus, the installation image for Perl includes: a bin directory containing perl and a2p (among others); an info directory containing Texinfo documentation; a lib/perl directory containing Perl libraries; and a man/man1 directory containing man pages.
A ``package directory'' is the root of a tree containing the installation image for a particular package. Each package directory must reside in a stow directory--e.g., the package directory /usr/local/stow/perl must reside in the stow directory /usr/local/stow. The ``name'' of a package is the name of its directory within the stow directory--e.g., perl.
Thus, the Perl executable might reside in /usr/local/stow/perl/bin/perl, where /usr/local is the target directory, /usr/local/stow is the stow directory, /usr/local/stow/perl is the package directory, and bin/perl within is part of the installation image.
A ``symlink'' is a symbolic link. A symlink can be ``relative'' or ``absolute''. An absolute symlink names a full path; that is, one starting from /. A relative symlink names a relative path; that is, one not starting from /. The target of a relative symlink is computed starting from the symlink's own directory. Stow only creates relative symlinks.
For example, suppose that no packages have yet been installed in /usr/local; it's completely empty (except for the stow subdirectory, of course). Now suppose the Perl package is installed. Recall that it includes the following directories in its installation image: bin; info; lib/perl; man/man1. Rather than creating the directory /usr/local/bin and populating it with symlinks to ../stow/perl/bin/perl and ../stow/perl/bin/a2p (and so on), Stow will create a single symlink, /usr/local/bin, which points to stow/perl/bin. In this way, it still works to refer to /usr/local/bin/perl and /usr/local/bin/a2p, and fewer symlinks have been created. This is called ``tree folding'', since an entire subtree is ``folded'' into a single symlink.
To complete this example, Stow will also create the symlink /usr/local/info pointing to stow/perl/info; the symlink /usr/local/lib pointing to stow/perl/lib; and the symlink /usr/local/man pointing to stow/perl/man.
Now suppose that instead of installing the Perl package into an empty target tree, the target tree is not empty to begin with. Instead, it contains several files and directories installed under a different system-administration philosophy. In particular, /usr/local/bin already exists and is a directory, as are /usr/local/lib and /usr/local/man/man1. In this case, Stow will descend into /usr/local/bin and create symlinks to ../stow/perl/bin/perl and ../stow/perl/bin/a2p (etc.), and it will descend into /usr/local/lib and create the tree-folding symlink perl pointing to ../stow/perl/lib/perl, and so on. As a rule, Stow only descends as far as necessary into the target tree when it can create a tree-folding symlink.
The time often comes when a tree-folding symlink has to be undone because another package uses one or more of the folded subdirectories in its installation image. This operation is called ``splitting open'' a folded tree. It involves removing the original symlink from the target tree, creating a true directory in its place, and then populating the new directory with symlinks to the newly-installed package and to the old package that used the old symlink. For example, suppose that after installing Perl into an empty /usr/local, we wish to install Emacs. Emacs's installation image includes a bin directory containing the emacs and etags executables, among others. Stow must make these files appear to be installed in /usr/local/bin, but presently /usr/local/bin is a symlink to stow/perl/bin. Stow therefore takes the following steps: the symlink /usr/local/bin is deleted; the directory /usr/local/bin is created; links are made from /usr/local/bin to ../stow/emacs/bin/emacs and ../stow/emacs/bin/etags; and links are made from /usr/local/bin to ../stow/perl/bin/perl and ../stow/perl/bin/a2p.
When splitting open a folded tree, Stow makes sure that the symlink it is about to remove points inside a valid package in the current stow directory. Stow will never delete anything that it doesn't own. Stow ``owns'' everything living in the target tree that points into a package in the stow directory. Anything Stow owns, it can recompute if lost. Note that by this definition, Stow doesn't ``own'' anything in the stow directory or in any of the packages.
If Stow needs to create a directory or a symlink in the target tree and it cannot because that name is already in use and is not owned by Stow, then a conflict has arisen. See ``Conflicts'' in the info manual.
To delete a package, Stow recursively scans the target tree, skipping over the stow directory (since that is usually a subdirectory of the target tree) and any other stow directories it encounters (see ``Multiple stow directories'' in the info manual). Any symlink it finds that points into the package being deleted is removed. Any directory that contained only symlinks to the package being deleted is removed. Any directory that, after removing symlinks and empty subdirectories, contains only symlinks to a single other package, is considered to be a previously ``folded'' tree that was ``split open.'' Stow will re-fold the tree by removing the symlinks to the surviving package, removing the directory, then linking the directory back to the surviving package.
Currently known bugs include: