Why not use stow for a distro?

Why not base a distro on stow?

What Stow is

Stow is a Perl package by Bob Glickstein that helps install packages cleanly. More cleanly than you might think possible, if you're familiar with traditional installation. It works like this:

• You install the package entirely inside one directory, usually a subdirectory of usr/local/stow No part of it is in bin or usr/bin or usr/doc etc, all in the one directory.
  • We'll say it's in /usr/local/stow/foo-1.0
• You command:

  cd /usr/local/stow/ 
  stow foo-1.0
  

• That makes symlinks from usr/doc, usr/bin, etc into the stow/foo-1.0 directory tree.
• Now the package is available just as if it had been installed.
• Want it gone? Just

  stow -D foo-1.0
  

This is neat in every sense of the word. It can manage multiple versions of a package neatly too.

Why they fit together

One task that a distro such as Debian or Redhat puts a lot of work into is package management. New packages typically put files in many places such as usr/bin, and a distro's package manager has to track where they go so it knows what to remove when deinstalling or upgrading. It has to use various tricks such as renaming old versions of config files.

But stow's way is cleaner. Why not do it that way?

Also, traditional distros aren't too happy with source distributions. They can compile them when they have a source package in their own format, but that mostly misses the point.

Mostly you compile in order to get the latest (stable or bleeding edge) version of something. For instance, I compiled GEDA today. I wanted the latest because the version in the Debian lenny distro doesn't handle everything that gschem outputs.

There was not a Debian package of the latest geda-gaf source, and I didn't really expect there to be. So I downloaded the latest and compiled it. Now Debian/dpkg/aptitude not only didn't help me, it was actually in conflict with what I was doing. Of course then dpkg couldn't manage its prerequisites for me, so I have to do that chore manually. Worse, the distro has its own idea of what is provided and what isn't, and what I'm compiling doesn't count in its eyes.

I didn't want to install on top of a version that aptitude installed, because that will confuse it. So I told aptitude to remove the package. That breaks depenencies and there is no reasonable way to tell aptitude that what I just compiled satisfies the dependency - to do that I'd have to create a Debian package for it, and still aptitude would treat it as a suspicious local package. So I had to remove easyspice, which I didn't want to. I probably have to fetch and compile it - even though I have it. Debian package management thinks it knows better than me.

And it occurred to me that it didn't have to be that way. The biggest reason why the stuff I compiled didn't have equal standing was the need to manage where packages put their files. It can't easily mix distro'd packages and compiled source because there's nothing to tell it which files the source "owns." Stow does that cleanly, and could do so even for a mix of distro'd packages and compiled source.

Digression

And would it be so hard to make autoconf's ./configure tell a package manager about missing prerequisites? Most of them were just the *-dev parts of packages I already had. I'm not too familiar with autoconf, but the only fundamental problem I see is a lack of a common agreed-on format.

Downside: Stow needs to bootstrap

Obviously this can't work for every package, since stow itself depends on a number of packages including a kernel and a Perl interpreter. Aside from Perl's intrinsic yukkiness, that also means that the Perl interpreter and its sizable standard libraries must be available.

There are, happily, a number of variants or offshoots: Graft, ln_local, Reflect, Sencap, Toast. However they mostly seem to be in Perl as well. One exception is Reflect, which requires only bash and coreutils. Unfortunately, Reflect appears to be abandoned.

But they don't agree on install-time config management

Stow won't replace install-time config management, though. Compiling from source typically doesn't have that at all; things are configged at build time with ./configure.

That's a problem. Distro'd packages and compiled source just don't agree on when to config.

Stow should have been done years ago

Years back, I thought that package management via symlinks and dedicated trees would be a neat idea. I never did anything about it. Bob Glickstein did. He's also done a number of other neat forward-looking things, including sregex for emacs.