sensible software installation

[Kragen Sitaker]

OK, here's a scheme that makes it possible to reliably install,
upgrade, and uninstall software without breaking other software.  It
won't work for the kernel --- obviously upgrading from Win98 to Linux
will break a lot of software no matter what you do.  But it will work
for most things.

When you install a piece of software, instead of sticking it somewhere
in the filesystem, you stuff it in a box.  Whenever this software runs,
this box --- it could be implemented as a chroot jail on Linux, but that
would suck --- determines its view of the world.  The software can't see
anything that isn't in the box when it's invoked (except for things that
get passed in from the outside by the invoker).

You don't put anything in the box that the software doesn't need.  But
if it needs, for example, a dynamically-linkable C library, you stick a
link to the C library's box in there.

When you upgrade software, you don't change the old box.  You make a new
box.  Other software that depends on the old version of the software
will keep using the old version unless you change it.

You need some kind of naming scheme --- something analogous to Debian's
/etc/alternatives (man update-alternatives if you have Debian) and
virtual packages and package names --- to indicate when two pieces of
software are in some sense the same, i.e. one is supposed to be a
drop-in replacement for the other one.  New software you install needs
to declare its needs in terms of this naming scheme so you know what to
put in its box so it will run.  Presumably you will want to specify
a policy for each name for which there is more than one alternative
available --- always use a particular alternative or let the user
choose, for example.

The user would normally be running in a box with links to many other
boxes corresponding to their files and software packages they have
installed.

When you wanted to uninstall a package, you would determine which other
packages had links to it.  You might want to uninstall these, leave them
in a broken state, or relink them to an alternative for that package.

This scheme has the following disadvantages compared to the Debian
system:
- it doesn't work because it hasn't been implemented.  No doubt when it
  is implemented it won't be as smooth as it seems to me right now.
- it is hard to implement on top of Unix, and impossible to implement
  fully (although capabilities will help.)  The Unix version will
  inevitably be somewhat inflexible and crufty.  EROS and Hurd seem more
  hospitable.
- it doesn't work for the kernel itself, because other programs'
  interface to the kernel cannot be so controlled.

It has the following advantages:
- it would work more reliably; ad-hoc packaging schemes that don't
  restrict their victims' view of the filesystem, like RPM and dpkg,
  fail when their victims have dependencies they don't know about.

- multiple versions of any package could always coexist.  You could
  reasonably have five different mail transport agents installed on the
  same machine, although only one of them could listen on port 25 on a
  particular network interface, along with ten different versions of
  Perl --- all installed as the default version for some applications
  and/or users.

  Obviously this is enough rope to shoot yourself in the foot, but it's
  also potentially very useful if you have a lot of users.

- the various schemes Debian uses for trying to figure out whether
  a particular dependency is satisfied (virtual packages, multiple
  versions of the same package) and for trying to find a program to do a
  particular function (/usr/lib/sendmail, /etc/alternatives/editor,
  etc.) are all unified.
  
- the box system is useful for other reasons if it is airtight; it would
  sure be nice to run groff or ghostscript in a jail where they couldn't
  modify existing files.

- things like the old relink-Xaw-programs-to-use-Xaw3d trick would be
  considerably easier.

- individual users could install their own software from the same
  packages the sysadmins would use to install it, without going to
  unreasonable lengths.  (This is an advantage of the old tar xzvf
  foo-1.tar.gz; cd foo; ./configure --prefix=/my/foo && make install
  system that dpkg and rpm have lost, as far as I can tell.)