[MacPorts] #65715: subversion-perlbindings: subports conflict

[MacPorts]

#65715: subversion-perlbindings: subports conflict
--------------------------------------+--------------------
  Reporter:  aikebah                  |      Owner:  (none)
      Type:  defect                   |     Status:  new
  Priority:  Normal                   |  Milestone:
 Component:  ports                    |    Version:
Resolution:                           |   Keywords:
      Port:  subversion-perlbindings  |
--------------------------------------+--------------------

Comment (by jmroot):

 Replying to [comment:3 jmroot]:
 > At least not without requiring ports to never conflict, or making
 decisions on behalf of the user.

 Replying to [comment:4 danielluke]:
 > This specific case also wouldn't arise if we only included one set of
 p5-* ports in MacPorts instead of many versions of perl (which almost no
 one actually needs).

 So this is the "don't have conflicting ports" option…

 Replying to [comment:5 aikebah]:
 > Is something I could perfectly accept as an end-user had the svn-related
 ports been requested or when the p5-28 flavour of the port is also
 required (directly or transitively) by some other port that I had
 requested. (that is: there is also a conflict in ports that would be
 installed were I to request the same set of ports on a vanilla Macports
 install).
 > It is however not the expected behavior by me as an end-user when the
 requested port has upgraded its dependency to a newer version and
 installation of the same set of requested ports succeeds on a vanilla
 MacPorts install. Then I would expect the system to auto-deactivate the
 now orphaned transitively required ports to allow for the upgrade to the
 p5-34 version.

 …and this is the "make decisions for the user" option.

 So would you expect all unrequested ports that no longer have any
 dependents (i.e. "leaves") to be deactivated after upgrades? Or just the
 ones that would conflict with something that is installed as part of the
 upgrade? Either way it's a fairly major change in upgrade behaviour, and I
 can virtually guarantee that some other users would not expect it.

 In the specific case that the conflicting port is a leaf after the
 upgrade, what you suggest is theoretically possible, but harder than it
 sounds. Dependencies are upgraded before their dependents, so at the time
 that the new conflicting port is being installed, the version of the
 dependent that depends on the other conflicting port is still active. So
 the decision has to be made based on the projected future state of the
 registry after the upgrade completes, which is not information that is
 currently available. It also opens up new and interesting ways to leave
 the system in an inconsistent state if part of the upgrade fails, unless
 the speculative changes are tracked and rolled back correctly.

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