subversion-perlbindings: subports conflict

[aikebah (Hans Aikema)]

It is my understanding that 'port upgrade outdated' is meant to avoid issues with some packages upgraded and others not-yet.

However today I ran into a port upgrade outdated that runs into `Error: Can't install subversion-perlbindings-5.34 because conflicting ports are active: subversion-perlbindings-5.28 Error: Problem while installing subversion-perlbindings-5.34 `

Full upgrade log and overview of requested ports (post-upgrade-attempt) attached. Uninstall/reinstall was not a usable scenario, I ended up removing the git +svn flavor, followed by a repeated uninstall of leaves, followed by a reinstall of the git +svn flavor, which worked. However I believe for this scenario (upgrade outdated) macports should not run into the conflict but happily upgrade.

Appears to be related to the +svn flavor of the git port (git @2.37.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28+svn)

[ryandesign (Ryan Carsten Schmidt)]

The various subports of the subversion-perlbindings port (subversion-perlbindings-5.28, subversion-perlbindings-5.34, etc.) conflict with one another. You can only have one of them active at a time and you have to deactivate the other ones. MacPorts doesn't know whether you understand the consequences of deactivating a port, therefore MacPorts doesn't do it for you and makes you do it yourself.

The problem arose for you because you were using the +svn variant of the git port, which depends on a subport of p5-svn-simple which depends on a subport of subversion-perlbindings. Which subport it depends on changed recently: the default Perl version in MacPorts changed from 5.28 to 5.34. If you want git to continue to use Perl 5.28 you can use its +perl5_28 variant however we recommend you upgrade to Perl 5.34 with us.

The correct solution to the issue is that the subports of the subversion-perlbindings port should be made not to conflict with one another, and the ports that depend on the subversion-perlbindings subports will need to be adapted to that change.

[jmroot (Joshua Root)]

There's really no way to avoid the need for manual intervention when there are two conflicting ports, you have one of them installed, and then you try to install something that requires the other (that applies equally to upgrading to new versions that add a new dependency). At least not without requiring ports to never conflict, or making decisions on behalf of the user. IIRC there is an interactive prompt that gets used in some similar situations (if you don't have interactivity turned off) and lets the user choose whether to deactivate the currently active port or cancel installing the new one. We could possibly do that in this situation too, though it would have to handle the dependents, and the fundamental choice is still the same whether it's automated or not.

[danielluke (Daniel J. Luke)]

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).

[aikebah (Hans Aikema)]

There's really no way to avoid the need for manual intervention when there are two conflicting ports, you have one of them installed, and then you try to install something that requires the other (that applies equally to upgrading to new versions that add a new dependency)

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.

[danielluke (Daniel J. Luke)]

Replying to aikebah:

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.

+1 - this is an artifact of how we've chosen to support multiple perl5 versions (being installed at the same time). I've argued that we'd be better off just having one perl5 version (and it's constellation of p5 ports) and making this experience better than trying to keep supporting multiple versions (somewhat poorly), but the consensus hasn't agreed with me.

[jmroot (Joshua Root)]

Replying to jmroot:

At least not without requiring ports to never conflict, or making decisions on behalf of the user.

Replying to 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 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.