1 .TH STOW 8 "28 March 1998"
3 stow \- software package installation manager
9 This manual page describes GNU Stow 1.3.3, a program for managing the
10 installation of software packages. This is not the definitive
11 documentation for stow; for that, see the info manual.
13 Stow is a tool for managing the installation of multiple software
14 packages in the same run-time directory tree. One historical difficulty
15 of this task has been the need to administer, upgrade, install, and
16 remove files in independent packages without confusing them with other
17 files sharing the same filesystem space. For instance, it is common to
18 install Perl and Emacs in
20 When one does so, one winds up
21 (as of Perl 4.036 and Emacs 19.22)
22 with the following files in
23 .IR /usr/local/man/man1 :
33 suppose it's time to uninstall Perl. Which man pages get removed?
36 is one of them, but it should not be the
37 administrator's responsibility to memorize the ownership of individual
38 files by separate packages.
40 The approach used by Stow is to install each package into its own
41 tree, then use symbolic links to make it appear as though the files are
42 installed in the common tree. Administration can be performed in the
43 package's private tree in isolation from clutter from other packages.
44 Stow can then be used to update the symbolic links. The structure of
45 each private tree should reflect the desired structure in the common
46 tree; i.e. (in the typical case) there should be a
49 containing executables, a
51 directory containing section 1 man
54 Stow was inspired by Carnegie Mellon's Depot program, but is
55 substantially simpler and safer. Whereas Depot required database files
56 to keep things in sync, Stow stores no extra state between runs, so
57 there's no danger (as there was in Depot) of mangling directories when
58 file hierarchies don't match the database. Also unlike Depot, Stow will
59 never delete any files, directories, or links that appear in a Stow
61 .IR /usr/local/stow/emacs ),
62 so it's always possible to
63 rebuild the target tree (e.g.,
66 A ``package'' is a related collection of files and directories that
67 you wish to administer as a unit--e.g., Perl or Emacs--and that needs
68 to be installed in a particular directory structure--e.g., with
75 A ``target directory'' is the root of a tree in which one or more
78 to be installed. A common, but by no means
79 the only such location is
81 The examples in this manual page
84 as the target directory.
86 A ``stow directory'' is the root of a tree containing separate
87 packages in private subtrees. When Stow runs, it uses the current
88 directory as the default stow directory. The examples in this manual
91 as the stow directory, so that individual
92 packages will be, for example,
93 .I /usr/local/stow/perl
95 .IR /usr/local/stow/emacs .
97 An ``installation image'' is the layout of files and directories
98 required by a package, relative to the target directory. Thus, the
99 installation image for Perl includes: a
107 directory containing Texinfo
110 directory containing Perl libraries; and a
112 directory containing man pages.
114 A ``package directory'' is the root of a tree containing the
115 installation image for a particular package. Each package directory
116 must reside in a stow directory--e.g., the package directory
117 .I /usr/local/stow/perl
118 must reside in the stow directory
119 .IR /usr/local/stow .
120 The ``name'' of a package is the name of its
121 directory within the stow directory--e.g.,
124 Thus, the Perl executable might reside in
125 .IR /usr/local/stow/perl/bin/perl ,
131 is the stow directory,
132 .I /usr/local/stow/perl
133 is the package directory, and
136 is part of the installation image.
138 A ``symlink'' is a symbolic link. A symlink can be ``relative'' or
139 ``absolute''. An absolute symlink names a full path; that is, one
142 A relative symlink names a relative path; that is,
143 one not starting from
145 The target of a relative symlink is
146 computed starting from the symlink's own directory. Stow only creates
149 The stow directory is assumed to be the current directory, and the
150 target directory is assumed to be the parent of the current directory
151 (so it is typical to execute
154 .IR /usr/local/stow ).
157 given on the command line is the name of a package in the stow
160 By default, they are installed into the
161 target directory (but they can be deleted instead using `-D').
166 Do not perform any operations that modify the filesystem; merely
167 show what would happen. Since no actual operations are performed,
169 could report conflicts when none would actually take
170 place (see ``Conflicts'' in the info manual);
171 but it won't fail to report conflicts
179 Do not exit immediately when a conflict is encountered. This
180 option implies `-n', and is used to search for all conflicts that
181 might arise from an actual Stow operation. As with `-n', however,
182 false conflicts might be reported (see ``Conflicts'' in the info manual).
187 Set the stow directory to DIR instead of the current directory.
188 This also has the effect of making the default target directory be
194 Set the target directory to DIR instead of the parent of the stow
200 Send verbose output to standard error describing what Stow is
201 doing. Verbosity levels are 0, 1, 2, and 3; 0 is the default.
202 Using `-v' or `--verbose' increases the verbosity by one; using
203 `--verbose=N' sets it to N.
208 Delete packages from the target directory rather than installing
214 Restow packages (first unstow, then stow again). This is useful
215 for pruning obsolete symlinks from the target tree after updating
216 the software in a package.
221 Show Stow version number, and exit.
226 Show Stow command syntax, and exit.
227 .SH "INSTALLING PACKAGES"
228 The default action of Stow is to install a package. This means
229 creating symlinks in the target tree that point into the package tree.
230 Stow attempts to do this with as few symlinks as possible; in other
231 words, if Stow can create a single symlink that points to an entire
232 subtree within the package tree, it will choose to do that rather than
233 create a directory in the target tree and populate it with symlinks.
235 For example, suppose that no packages have yet been installed in
237 it's completely empty (except for the
239 subdirectory, of course). Now suppose the Perl package is installed.
240 Recall that it includes the following directories in its installation
249 and populating it with symlinks to
250 .I ../stow/perl/bin/perl
252 .I ../stow/perl/bin/a2p
254 will create a single symlink,
258 In this way, it still works to refer to
259 .I /usr/local/bin/perl
261 .IR /usr/local/bin/a2p ,
262 and fewer symlinks have
263 been created. This is called ``tree folding'', since an entire subtree
264 is ``folded'' into a single symlink.
266 To complete this example, Stow will also create the symlink
279 Now suppose that instead of installing the Perl package into an empty
280 target tree, the target tree is not empty to begin with. Instead, it
281 contains several files and directories installed under a different
282 system-administration philosophy. In particular,
284 already exists and is a directory, as are
287 .IR /usr/local/man/man1 .
288 In this case, Stow will descend into
290 and create symlinks to
291 .I ../stow/perl/bin/perl
293 .I ../stow/perl/bin/a2p
294 (etc.), and it will descend into
296 and create the tree-folding symlink
299 .IR ../stow/perl/lib/perl ,
300 and so on. As a rule, Stow only descends as
301 far as necessary into the target tree when it can create a tree-folding
304 The time often comes when a tree-folding symlink has to be undone
305 because another package uses one or more of the folded subdirectories in
306 its installation image. This operation is called ``splitting open'' a
307 folded tree. It involves removing the original symlink from the target
308 tree, creating a true directory in its place, and then populating the
309 new directory with symlinks to the newly-installed package
312 old package that used the old symlink. For example, suppose that after
313 installing Perl into an empty
315 we wish to install Emacs.
316 Emacs's installation image includes a
318 directory containing the
322 executables, among others. Stow must make these
323 files appear to be installed in
330 the following steps: the symlink
335 is created; links are made from
338 .I ../stow/emacs/bin/emacs
340 .IR ../stow/emacs/bin/etags ;
341 and links are made from
344 .I ../stow/perl/bin/perl
346 .IR ../stow/perl/bin/a2p .
348 When splitting open a folded tree, Stow makes sure that the symlink
349 it is about to remove points inside a valid package in the current stow
351 .BR "Stow will never delete anything that it doesn't own" .
352 Stow ``owns'' everything living in the target tree that points into a
353 package in the stow directory. Anything Stow owns, it can recompute if
354 lost. Note that by this definition, Stow doesn't ``own'' anything
356 the stow directory or in any of the packages.
358 If Stow needs to create a directory or a symlink in the target tree
359 and it cannot because that name is already in use and is not owned by
360 Stow, then a conflict has arisen. See ``Conflicts'' in the info manual.
361 .SH "DELETING PACKAGES"
362 When the `-D' option is given, the action of Stow is to delete a
363 package from the target tree. Note that Stow will not delete anything
364 it doesn't ``own''. Deleting a package does
366 mean removing it from
367 the stow directory or discarding the package tree.
369 To delete a package, Stow recursively scans the target tree,
370 skipping over the stow directory (since that is usually a subdirectory
371 of the target tree) and any other stow directories it encounters (see
372 ``Multiple stow directories'' in the info manual). Any symlink it finds that points into
373 the package being deleted is removed. Any directory that contained
374 only symlinks to the package being deleted is removed. Any directory
375 that, after removing symlinks and empty subdirectories, contains only
376 symlinks to a single other package, is considered to be a previously
377 ``folded'' tree that was ``split open.'' Stow will re-fold the tree by
378 removing the symlinks to the surviving package, removing the directory,
379 then linking the directory back to the surviving package.
381 The info manual ``Stow 1.3.3:
382 Managing the installation of software packages''
383 by Bob Glickstein, Zanshin Software, Inc.
385 Please report bugs in Stow using the Debian bug tracking system.
387 Currently known bugs include:
389 The empty-directory problem. If package FOO includes an empty
390 directory--say, FOO/BAR--then:
393 if no other package has a BAR subdirectory, everything's fine.
396 if another stowed package, QUUX, has a BAR subdirectory, then
397 when stowing, TARGETDIR/BAR will be ``split open'' and the
398 contents of QUUX/BAR will be individually stowed. So far, so
399 good. But when unstowing QUUX, TARGETDIR/BAR will be
400 removed, even though FOO/BAR needs it to remain. A
401 workaround for this problem is to create a file in FOO/BAR as
402 a placeholder. If you name that file
405 be easy to find and remove such files when this bug is fixed.
407 When using multiple stow directories (see ``Multiple stow
408 directories'' in the info manual), Stow fails to ``split open'' tree-folding symlinks
409 (see ``Installing packages'' in the info manual) that point into a stow directory
410 which is not the one in use by the current Stow command. Before
411 failing, it should search the target of the link to see whether
412 any element of the path contains a
414 file. If it finds one,
415 it can ``learn'' about the cooperating stow directory to
418 search the next time it encounters a
419 tree-folding symlink.
421 This man page was constructed by Charles Briscoe-Smith from
422 parts of Stow's info manual. That manual contained the following
423 notice, which, as it says, applied to this manual page, too. The text
424 of the section entitled ``GNU General Public License'' can be found in
426 .I /usr/share/common-licenses/GPL
427 on any Debian GNU/Linux system. If you don't have access to a Debian
428 system, or the GPL is not there, write to the Free Software Foundation,
429 Inc., 59 Temple Place, Suite 330, Boston, MA, 02111-1307, USA.
431 Software and documentation Copyright (C) 1993, 1994, 1995, 1996 by
432 Bob Glickstein <bobg+stow@zanshin.com>.
434 Permission is granted to make and distribute verbatim copies of this
435 manual provided the copyright notice and this permission notice are
436 preserved on all copies.
438 Permission is granted to copy and distribute modified versions of
439 this manual under the conditions for verbatim copying, provided also
440 that the section entitled ``GNU General Public License'' is included with
441 the modified manual, and provided that the entire resulting derived
442 work is distributed under the terms of a permission notice identical to
445 Permission is granted to copy and distribute translations of this
446 manual into another language, under the above conditions for modified
447 versions, except that this permission notice may be stated in a
448 translation approved by the Free Software Foundation.