fao_ <finnole...@inventati.org> 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 <a...@offog.org> <http://offog.org/>
