>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.
  >
  How?  I've used FreeBSD ports for years and have never seen this...
  Care to elaborate?  The multiple versions of libraries are usually
  tucked away in lib/compat after an upgrade to insure packages continue
  to work after upgrades, as you point out below.

I'm not talking about lib/compat, but libraries provided by ports.
With pkgsrc, a pkg conflicts with older versions of itself, so doing a
'make install' fails if an older version is installed.  With ports, at
least in the past, the second copy would be installed and registered.

This can happen by doing a 'make package' of port A, which depends on
libfoo.  Version 1.0 of libfoo gets installed.  Wait 3 months and cvs
update.  Do 'make package' of port B, which also requires libfoo, but
now the libfoo Makefile says 1.1 is current and needed, so libfoo 1.1
gets installed.  I have seen this multiple times, and when starting to
use portupgrade many such situations needed to be cleaned up.

To check that this behavior still occurs, I went to a FreeBSD box
running 4.9-RC with ports from November 5.  glib-1.2.8 was installed.
I went to devel/glib12 and did 'make package'.  Now glib-1.2.8 and
glib-1.2.10_10 are both installed.  I deleted glib-1.2.8, which
complained about files not matching the MD5 checksum.  I delete
glib-1.2.10_10, which complained about
/usr/local/share/aclocal/glib.m4 not exising (probably because it was
deleted by 1.2.8).

In this case I was trying to install something that was already
installed, so one could claim it was my fault.  But a large part of
the point of ports/pkgsrc is to build/install dependencies without
having to understand them.

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

  Once you install portupgrade it will manage itself and it's
  dependencies (including ruby) as part of normal business.  So what's
  the big deal with this?

This is tech-pkg, and so the point is discussing features of other
package systems that might be appropriate to adopt into pkgsrc.  It is
my judgement that pkgsrc is not going to incorporate tools written in
ruby, and I thought it useful to point this out to others.

  So administrate your system properly.  Unless of course you can
  explain how exactly you get to a point where you have multiple
  versions of a port installed without intentionally misusing the
  ports-system it's your fault, not the ports-system.

I'm afraid we simply differ on this.  I don't consider simply doing
'make package' in some port to be incorrect administration.  If one
always uses portupgrade for all operations and forsakes direct use of
the native tools, and perhaps also does a full upgrade cycle after
each cvs update, then yes portupgrade can work well - and that's what
I tried to say.  I have found the system to be very unforgiving of
operations that I consider reasonable, although I suspect most of this
could be fixed by addressing the duplicate package installation issue
and merging portupgrade into the base tools.

But, the germane questions are what sort of features inspired by
portupgrade should be incorporated into pkgsrc.

I see a number of things that would be useful:

  augment 'make replace' to make it safer by saving old shlibs
  (probably via Frederick's pkg_hack or something similar)

  keep track of packages made unsafe by 'make replace'

  tsort dependencies and do 'make replace' operations in a sensible
  order

The first two really should be integrated into the base pkgsrc
system.

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