Re: [Help-stow] Introducing GNU Guix

[Adam Spiers]

[cross-posting to help-stow]

On Mon, Nov 26, 2012 at 10:32 PM, Adam Sampson <address@hidden> wrote:
> Richard Stallman <address@hidden> writes:
>
>> Is Stow still useful, or should we think of Guix as a replacement for it?
>
> Stow is definitely still useful. I'm aware of two universities that use
> it internally for package management on large numbers of POSIX-ish
> systems

Good to know!  Do you know if they have switched to any of the new
2.x releases I made in the last year?

> and I maintain a GNU/Linux distribution that uses it for
> package management (GARStow, which was the basis for GSRC).
>
> Something like Guix is the right way to go if you're designing a new
> system from scratch, but Stow is very effective for simple package
> management inside an existing system.

One fundamental difference between Stow and most popular package
managers is that due to the use of symlinks, when you are writing to a
file "installed" from a Stow package, you are really writing to the
file associated with the package definition, rather than an installed
copy.  IOW, you are actually *modifying* the package itself.  With
Stow, reverting this change is only possible if there is some kind of
out-of-band version control associated with the package.  In
comparison, with something like rpm or deb, you could revert by
reinstalling from the pristine binary package.

This might sound like a flaw, but it's actually a great advantage in
the "manage my home directory" use case, because when your Stow
packages are say, git repositories, it means you can directly hack on
your config files from within your home directory using version
control, without having to worry about which repository they are
associated with:

  1. edit ~/.bashrc
  2. test
  3. repeat steps 1--2 until tests succeed
  4. commit (or revert if tests didn't succeed)

The package building paradigm is simply too heavyweight for this use
case, because changing a config file would require more steps:

  1. remember where .bashrc lives in corresponding package sources
  2. edit it
  3. rebuild a new version of the package
  4. upgrade to the new version
  5. test
  6. repeat steps 2--5 until tests succeed
  7. commit (or revert and downgrade if tests didn't succeed)

There is an alternative approach which is quite popular right now:

  https://github.com/RichiH/vcsh#readme

This is similar to the Stow-based approach, except that it is
dependent on git's detached working trees feature, and requires you to
remember which repository the files you are modifying are associated
with, whenever you perform a version control action such as commit /
add / remove.  But it is preferable for those with an allergy to
symlinks (which AFAICS tends to be an aesthetic judgement rather than
one based on technical reasons).

At some point I would love to find the time to publish an article
about package-oriented management of home directories, which would
compare and contrast these two approaches (Stow vs. vcsh).  They both
have their merits, and downsides (e.g. lack of dependency management).

Adam