[MacPorts] #57099: [feature request] "replaces" keyword

[MacPorts]

#57099: [feature request] "replaces" keyword
--------------------------+--------------------
  Reporter:  RJVB         |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------
Description changed by RJVB:

Old description:

> The Debian/Ubuntu package manager has a feature that allows packages to
> register as a replacement for another package. This is a more direct
> complement to the MacPorts `replaced_by` feature.
>
> I see a few points of interest to a "this port replaces this and that
> other port(s)":
>
> - it's not an EOL property; for instance, `port:foo` and `port:foo-devel`
> could both use `replaces foo-devel` and `replaces foo` respectively. This
> would streamline the process of switching between a port and its "devel"
> counterpart because the install/upgrade (or even activation) procedure
> for the one would first deactivate the other.
> - it should also streamline upgrades when a new port replaces a more than
> a single port.
>
> `port:xorg-xorgproto` is probably a good example for that second point. I
> had some issues when I did a (partial) upgrade using `port upgrade
> outdated and "xorg-*proto"`. If `xorg-xorgproto` had registerd the
> `replaces` list of all proto ports it replaces, those ports would all
> have been deactivated at once, when the first to-be-replaced proto port
> upgrade was being processed.

New description:

 The Debian/Ubuntu package manager has a feature that allows packages to
 register as a replacement for another package. This is a more direct
 complement to the MacPorts `replaced_by` feature.

 I see a few points of interest to a "this port replaces this and that
 other port(s)":

 - it's not an EOL property; for instance, `port:foo` and `port:foo-devel`
 could both use `replaces foo-devel` and `replaces foo` respectively. This
 would streamline the process of switching between a port and its "devel"
 counterpart because the install/upgrade (or even activation) procedure for
 the one would first deactivate the other.
 - it should also streamline upgrades when a new port replaces more than a
 single port.

 `port:xorg-xorgproto` is probably a good example for that second point. I
 had some issues when I did a (partial) upgrade using `port upgrade
 outdated and "xorg-*proto"`. If `xorg-xorgproto` had registered the
 `replaces` list of all proto ports it replaces, those ports would all have
 been deactivated at once, when the first to-be-replaced proto port upgrade
 was being processed.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/57099#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS