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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
