port upgrade outdated order

[René J.V. Bertin]

On Wednesday March 04 2015 17:16:29 Mihai Moldovan wrote:

> Our current workaround for this is the conflicts_build PortGroup, which
> bails out and asks the user to deactivate the port in question. This is
> ugly for several reasons:
>   - it requires interactivity
>   - a deactivated port is not listed in ``port outdated'' and can NOT be
> used with ``port upgrade'', but must be re-installed with ``port
> installed''.

One can just activate any of the installed versions, and then do a port upgrade, no? That should be fine once the port requiring the deactivation has been built.

On a related note: it'd be nice if MacPorts could be a little bit more proactive in deactiving conflicting ports. Like when installing a subport that conflicts with one of its siblings. If both are at the same version I don't see why `port install foo-B` wouldn't cause the automatic deactivation of port:foo-A as long as foo-A doesn't provide anything others depend upon that foo-B doesn't provide. Same for say qt5-mac and qt5-mac-devel, which are interchangeable but cannot be installed at the same time. If I install or activate the one, the other could be deactivated automatically.
(just to be sure, if you declare a path: style dependency, the provided path is recorded in the registry, right?)

R.