portupgrade problems: "already installed"

munk over at freebsd.munk.me.uk writes this in his recent post "Portupgrade fails to upgrade dependencies":

An example is when I just went to run the weekly 'portupgrade -arR' and whilst upgrading p5-PathTools-3.21, portupgrade found that another port - p5-Scalar-List-Utils-1.18 - also needed upgrading. Unfortunately the upgrade of that port failed with the following error:

===>  Checking if lang/p5-Scalar-List-Utils already installed
===>   p5-Scalar-List-Utils-1.18,1 is already installed
     You may wish to ``make deinstall'' and install this port again
     by ``make reinstall'' to upgrade it properly.
     If you really wish to overwrite the old port of lang/p5-Scalar-List-Utils
     without deleting it first, set the variable "FORCE_PKG_REGISTER"
     in your environment or the "make install" command line.
*** Error code 1

Stop in /home/munk/ports/lang/p5-Scalar-List-Utils.
*** Error code 1

Stop in /home/munk/ports/devel/p5-PathTools.

This is not how portupgrade usually works, but I've definitely seen this sort of thing before. Normally, it can find the dependencies and upgrade them in order (even if you only use the '-a' option alone). Though, order isn't even critical, since it builds first (without dependencies), then uninstalls the old one, and then jerry-rigs the dependencies as necessary when installing.

Tracing the errors, it appears that the first error is coming from ports system itself ("p5-Scalar-List-Utils-1.18,1 is already installed You may wish to ...."), not portupgrade, and that the p5-PathTools build/make called the p5-Scalar-List-Utils make/install (via the ports system, not portupgrade) . So, portupgrade's dependency ordering (and/or dependency rigging) has gone wrong somewhere.

When I get similar errors, I usually go back and attempt to portupgrade the problem port by itself (with whatever massaging might be necessary). To be clear, the "problem port" is the one appearing first in the traceback (in this case p5-Scalar-List-Utils-1.18,1). Then I proceed with another 'portupgrade -a' to finish up. This method has been reliable.

I recommend that when you see an error like the above, that you first attempt to tackle the problem port or ports one by one with a solo portupgrade. In fact, this should be how you handle a number of ports system errors that show through in a portupgrade run. The "FORCE_PKG_REGISTER" solution mentioned in the error output above is the ports system's no-frills, damn-the-torpedoes solution and might cause problems in the future as it has the potential to leave old files behind. (Okay, a little cruft never hurt anybody, but we still don't like it.)

Hardly relevant footnotes

But, I keep thinking back to those options: '-arR'. This is pure speculation, but could there be a conflict between them? The 'r' and 'R' options should be completely unnecessary when you have the 'a' option. ... Well, there's no need to guess -- I checked the portupgrade script (portupgrade-2.1.3.3_1,2 on my system) and they've already handled that: both recursion options are set false when 'all' is set and neither recursion option will be set if 'all' is already set.

Here's something to watch in the future: do these errors occur more with build dependencies or run dependencies? (This one was a run dependency.)