On the same note, what do people think of the portupgrade stuff in
  FreeBSD? I've just acquired a FreeBSD box to experiment on. One problem
  I can see is that it requires a binary INDEX.db that must be generated
  on the host with the ports tree. This would make it hard to share a 
  pkgsrc tree across multiple machines by NFS, which is what I do at home.
  Perhaps it's worth it, though...

It seems cool, but it can be quite painful in practice.  In my
department we have a number of both NetBSD and FreeBSD machines.  Our
sysadmin regularly updates each box along netbsd-1-6 or RELENG_4
branches, and also keeps pkgs/ports up to date.  He has been using
portupgrade.  My conclusion from observing all this as well as using
portupgrade on my own box (I won't speak for him) is that portupgrade
and FreeBSD ports is pretty scary to maintain, and that pkgsrc is far
easier to deal with.  My own box has since been moved to NetBSD, and
pkgsrc is one of the reasons.

Specific comments:

1. In FreeBSD ports, one can install multiple versions of a package.
   When starting to use portupgrade, we usually find that there are
   multiple versions of a lot of libraries, with many files claimed by
   multiple packages.

2. IIRC portupgrade is written in ruby, so you have to have that
   installed.  This has not been a hassle in practice.

3. portupgrade is an add-on, so it has new commands for lots of
   package operations in order to keep its extra databases in sync.
   The dbs get out of sync if you do regular operations, and then you
   have to rebuild them.

4. When all the dbs are in sync and the ports installation is 100%
   straightened out, portupgrade works very smoothly.

5. The basic operation of upgrading is somewhat like 'make replace',
   except that (I'm fuzzy on the details) it keeps old .so versions
   around to not break programs linked against them.  This is a very
   cool feature.


The lessons I take from all of this is:

1. Having a pkg system allow multiple installs of a package with
   overlapping file sets is madness, and causes a lot of trouble.
   It's annoying to have to make update a library when building a
   package with pkgsrc sometimes, but a net win in time spent.

2. Any new databases should probably be integrated into pkgsrc proper
   so that they are maintained during normal package operations.

3. Having a strategy to keep older versions of libraries around is
   very useful, and means that packages don't break when you upgrade
   their dependent libs so often.

So, it would be cool if make replace could diff the PLISTs, and if
there is an 'old' .so version, create a new splinter package
registration of just those files, and change the dependencies of all
depending packages to include both the new splinter package and the
replacement package.

Further, the splinter package could be marked as 'second class',
meaning that it only exists to support other packages, not because
anything wants it, and automatically deinstall it when the last
depending package is removed.

-- 
        Greg Troxel <gdt@ir.bbn.com>