On 04.03.2015 05:52 PM, René J.V. Bertin wrote: > 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?
If the port conflicts with *itself*? No, that's certainly impossible. It must be deactivated and "upgraded" via ``port install ...''. > 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. Probably because it has never been implemented. Patches welcome, I guess? Also, you'd have to make sure that foo-B builds correctly or, if it fails, activate foo-A again after it failed. I don't know whether MacPorts base can do this. I doubt it does. > (just to be sure, if you declare a path: style dependency, the provided path is recorded in the registry, right?) No, why? The path-based dependency is not part of the portfile that provides it, but some other, unrelated one. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
