I have to admit I don't fully understand what was the consequence of cancelling the upgrade in this case. Quoting the original report:
"port info gnupg claims that gnupg is at 1.4.5. The PortIndex file claims that gnupg is at 1.4.5. The Portfile claims that gnupg is at 1.4.5."
So far everything is consistent, info reads from the index and the index takes its information from what's listed in the Portfile. Carrying on:
"port outdated doesn't report gnupg as outdated. gnupg 1.4.4_0 has been deactivated, quietly leaving me without gpg."
If the final result and the cause for the bug report is that gnupg is left deactivated, maybe an argument that it should be reactivated before aborting could be made, but that's by no means a database inconsistency. Stephen, what happens if you try to reactivate the old gnupg manually after cancelling the upgrade?
Other than that, I'm not sure whether or not 'port outdated" looks at deactivated ports to do its magic, but in case it doesn't an argument that it should could easily be made too. But then again, that's another bug and/or feature request.
Setting this ticket to "Needs developer review" until we have more information on what's really at fault here, if anything.
-jmpp
