"port upgrade" tries to activate an installed version before building the new version

[vinc17@…]

I have the following problem:

prunille:~> port installed python24
The following ports are currently installed:
  python24 @2.4.3_1+darwin_8 (active)
  python24 @2.4.4_0+darwin_8
prunille:~> sudo port -v -d upgrade python24
DEBUG: Found port in file:///Users/vinc17/software/dports/lang/python24
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.macports.org_dpupdate_dports/lang/python24
--->  Activating python24 2.4.4_0+darwin_8
DEBUG: Image error: Another version of this port (python24 @2.4.3_1+darwin_8) is already active.
    while executing
"portimage::activate $portname $version_installed$variant $optionslist"
Error: Activating python24 2.4.4_0 failed: Image error: Another version of this port (python24 @2.4.3_1+darwin_8) is already active.
prunille:~> port info python24
Warning: Found 2 port python24 definitions, displaying first one.
python24 2.4.4, Revision 1, lang/python24 (Variants: universal, puredarwin, darwin_8)
[...]

"port upgrade" shouldn't have tried to activate version 2.4.4_0 since the goal is to build and install version 2.4.4_1.

[gwhitney@…]

Seems as though the component should be changed to "base", it seems as though it's unlikely that there's anything specific to python24 going on here, but rather general issues with update.

[vinc17@…]

Yes, I forgot to set Component to base...

[eridius@…]

IIRC, port upgrade does an activate first for some historical reason which I don't remember. The odd thing is that it's trying to activate the wrong version here - perhaps it defaults to activating the newest version, and you have an older version as the currently activated port?

[vinc17@…]

Yes, there are problems with the newer version, so that I have the older one activated.

[jmr@…]

proposed fix

[jmr@…]

The comment  here says that upgrade will deactivate any active version of the port before activating the latest installed version. The code to do that is broken though. The test around the deactivate call is always false, and the deactivate call itself doesn't use the full version spec (which would cause it to fail if it were ever actually reached).

The purpose of testing at all instead of just deactivating whatever's active seems to be to avoid deactivating if the latest version is already the one that is active. The attached patch should hopefully make this work as intended.

I'm also proposing this for the 1.6.1 milestone.

[jmr@…]

I've tested the patch and it seems to do the right thing in each of the different cases, so I committed it to trunk in r36762. Leaving this ticket open until the patch is merged into the 1.6 branch, or is retargeted to a later release.

[raimue@…]

Marking fixed, targeted for 1.7.0.