Upgrading specific port ignores epoch

[fhgwright (Fred Wright)]

While testing that the recent rollback change for openssl3 worked as intended, I found that it did not when applied to the individual port.

With the recent change temporarily removed, I repeated the bad upgrade to openssl3 3.2.0, which worked as intended:

MacPro:macports-ports fw$ sudo port upgrade openssl3
--->  Computing dependencies for openssl3
--->  Fetching archive for openssl3
--->  Attempting to fetch openssl3-3.2.0_0+universal.darwin_13.i386-x86_64.tbz2 from http://packages.macports.org/openssl3
[...]

I then unremoved the recent change, and checked the "outdated" status, which worked as intended:

MacPro:macports-ports fw$ port outdated
The following installed ports are outdated:
[...]
openssl3                       3.2.0_0 < 3.1.4_1  (epoch 0 < 1)  
[...]

But a plain upgrade of openssl3 didn't work:

MacPro:macports-ports fw$ sudo port upgrade openssl3
--->  Scanning binaries for linking errors
[...]

So had to force the issue:

MacPro:macports-ports fw$ sudo port -n upgrade --force openssl3
--->  Fetching archive for openssl3
--->  Attempting to fetch openssl3-3.1.4_1+universal.darwin_13.i386-x86_64.tbz2 from http://packages.macports.org/openssl3
[...]

It may well be that a plain upgrade outdated would have worked, but this usage should have worked as well.

Note that this particular case only applies to the OS versions affected by the rollback, meaning <10.14, though I suspect that the general problem applies to any case where an epoch bump is being used for a version downgrade.

[jmroot (Joshua Root)]

Works for me:

% port outdated
The following installed ports are outdated:
openssl                        3_15 < 3_16               
openssl3                       3.2.0_0 < 3.1.4_1  (epoch 0 < 1)  
% sudo port upgrade openssl3
--->  Computing dependencies for openssl3
--->  Fetching archive for openssl3
…

Debug output would be useful.

[neverpanic (Clemens Lang)]

Is there a chance that you had both versions installed but one of them inactive?

[fhgwright (Fred Wright)]

Replying to neverpanic:

Is there a chance that you had both versions installed but one of them inactive?

Bingo. I still had 3.1.4_1 installed, and it was probably from a build with the epoch bumped. After rolling it back to 3.1.4_0, gojng forward from there worked as intended.

I suspect that this related to the "held back hack". It seems that when the active version isn't the latest version, then "upgrade outdated" leaves it alone on the theory that if the user has an older version active, there's probably a reason for that and it should be left alone. That's reasonable in principle, but I think it would be more appropriate to apply that logic to the definition of "outdated" rather than to the action of "upgrade".

I see five possible mutually exclusive and exhaustive classifications for the installation status of a given port on a given system:

Current: the active instance is the newest installed version, and no newer version is available.

Outdated: the active instance is the newest installed version, and a newer version is available.

Held-back: the active instance is not the newest installed version.

Inactive: at least one instance is installed, but none is active.

Uninstalled: no instances are installed.

With that, "upgrade" should mean installing and activating the current version if it's newer than the active version, preserving variants to the extent possible, where "installing" might be a NOP if the relevant version/variants is already installed. No need for a "held back hack" in "upgrade" when "upgrade outdated" uses the above definition of "outdated"

A port uninstalled command would be pretty pointless, but having commands to list the other four classifications would be useful.

Having to use --force to upgrade a held-back port is problematic, because if one forgets to use -n, then it reinstalls every recursive dependency, sometimes having to rebuild from source. It's sufficiently unlikely that this is the intended behavior of --force (in general) that it might make sense to require confirmation.

[neverpanic (Clemens Lang)]

Replying to fhgwright:

Replying to neverpanic:

Is there a chance that you had both versions installed but one of them inactive?

Bingo. I still had 3.1.4_1 installed, and it was probably from a build with the epoch bumped. After rolling it back to 3.1.4_0, gojng forward from there worked as intended.

I suspect that this related to the "held back hack". It seems that when the active version isn't the latest version, then "upgrade outdated" leaves it alone on the theory that if the user has an older version active, there's probably a reason for that and it should be left alone. That's reasonable in principle, but I think it would be more appropriate to apply that logic to the definition of "outdated" rather than to the action of "upgrade".

Yes, the outdated pseudo-port does not include ports that have a newer inactive version and an older active version. So for that reason port upgrade outdated will not update them, but port upgrade openssl3 should have.

I see five possible mutually exclusive and exhaustive classifications for the installation status of a given port on a given system:

Current: the active instance is the newest installed version, and no newer version is available.

Outdated: the active instance is the newest installed version, and a newer version is available.

Held-back: the active instance is not the newest installed version.

Inactive: at least one instance is installed, but none is active.

Uninstalled: no instances are installed.

With that, "upgrade" should mean installing and activating the current version if it's newer than the active version, preserving variants to the extent possible, where "installing" might be a NOP if the relevant version/variants is already installed. No need for a "held back hack" in "upgrade" when "upgrade outdated" uses the above definition of "outdated"

I don't think we have hold-back functionality implemented in upgrade. It's simply that outdated does not include such prots. Check with port installed outdated.

A port uninstalled command would be pretty pointless, but having commands to list the other four classifications would be useful.

I think there's port installed actinact which lists such ports, but it's been a while.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

A port uninstalled command would be pretty pointless,

Agreed. We already have too many different commands that list ports (list, echo, installed, outdated); we should be consolidating the list commands not adding new ones. uninstalled is a valid pseudoport that expands to the list of ports that are not installed, and you can supply it to any of the existing commands that list ports. For example, port list uninstalled, port echo uninstalled, etc. port installed uninstalled, of course, prints "None of the specified ports are installed" and port outdated uninstalled, unsurprisingly, prints "None of the specified ports are outdated."