[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