[MacPorts] #68820: Upgrading specific port ignores epoch
MacPorts
noreply at macports.org
Sat Dec 2 21:44:49 UTC 2023
#68820: Upgrading specific port ignores epoch
------------------------+--------------------
Reporter: fhgwright | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version: 2.8.1
Resolution: | Keywords:
Port: |
------------------------+--------------------
Comment (by fhgwright):
Replying to [comment:2 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.
--
Ticket URL: <https://trac.macports.org/ticket/68820#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list