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: http://offog.org/code/garstow/
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
them.
Thanks,
--
Adam Sampson <http://offog.org/>
