Greg Troxel wrote:

>  >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.
>  
>
Yes  I think in summary the FreeBSD ports system works quite well with 
portupgrade but is quite deficient without it.  It's a shame that it is 
itself a port and not at least hooked in to their 'sysinstall' so that 
it can be installed with the OS.  Notably though the cleanup effort can 
be made not so painful with pkg_which and a few other tools they have to 
prune out old files.  I think the moral of the story in FreeBSD is if 
you're going to use FreeBSD ports the first command you should type is 
"cd /usr/ports/sysutils/portupgrade; make install".

>  >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.
>
>  
>
I should point out that FreeBSD's use of targets (definitions perhaps) 
differ slightly.  `make package' might not necessarily hold the same 
semantics, consequences, etc. in ports as pkgsrc.  None the less point 
taken.  I think the more-less obvious reason portupgrade can't go 
base-system in FreeBSD is reliance on ruby.

>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.
>
>  
>
I like you 'splinter package' idea for handling old shlibs personally.  
I still have not investigated the tsort dependencies handling but if it 
solves the problem I'm all for it.  In summary my stance is that I'd 
like pkgsrc to do everything that portupgrade does in pkgsrc, in the 
base system, period.

Adam