Re: [dev] Opinions on GNU stow

From: Adam Sampson <>
Date: Wed, 06 Sep 2017 12:53:11 +0100

fao_ <> writes:

> Rather, I am asking your opinions on the general concept and how it
> has been implemented. [...] But anything about the general behavior of
> it that you think especially sucky would help, also.

One of my pet projects is a distribution that uses stow for
package management:

So I've been running a number of systems on which everything (including
libc, the kernel, and so on) is managed using stow for the last fifteen
years. On the whole it works surprisingly well given the
brute-force-ness of the stow approach!

A few comments on things I've run into...

- stow being a Perl program is a bit awkward. Upgrading stow, Perl or
  any of Perl's dependencies requires some care from the package
  installation code to avoid breaking anything in mid-upgrade. As stow
  is really a pretty simple program (even with the new features that
  were added in recent versions), a medium-term plan for me is to
  rewrite it in a compiled language within GARStow's support tools.

- There's a design choice when implementing something like stow: when
  you're installing a directory into the target dir that belongs to a
  single package, do you create a symlink to the directory itself, or do
  you make a directory in the target dir and then create symlinks to
  non-directories within it? stow chose the first option; graft is an
  example of a stow-like tool that chose the second option.

  After lots of experience of using stow, I think the second option is
  better, since it's then much easier to identify files that were
  written directly to the target dir. Ideally you want package dirs to
  be immutable with stow.

- There are a very small number of programs (e.g. Python, Qt's qmake)
  that attempt to be a bit over-clever in identifying where they're been
  installed to, and get confused if they've been installed using stow.
  I've been able to patch these easily enough when I've encountered


Adam Sampson <>                         <>
Received on Wed Sep 06 2017 - 13:53:11 CEST

This archive was generated by hypermail 2.3.0 : Wed Sep 06 2017 - 14:00:19 CEST