On Mar 20, 2010, at 6:32 PM, Ryan Schmidt wrote:
On Mar 20, 2010, at 14:03, Kastus Shchuka wrote:
I forgot to mention that despite libevent mentioned in conflicts
lint in the qt4-mac port file, port command did not produce any
error message about conflicting port installed:
Is it because I am upgrading and not installing qt4-mac?
Yes, the conflicts mechanism appears to only take effect when
installing, not when upgrading.
I guess the problem is that there are (at least) two different types
of conflicts we're trying to model in the single "conflicts" keyword:
1. A port that installs the same files as another port (e.g. qt4-mac
and qt4-mac-devel). They cannot be active at the same time, but they
can be installed at the same time, and they don't interfere with one
another at build time. If one port is already active (e.g. qt4-mac
is active) and you try to upgrade it, then logically qt4-mac-devel
cannot already have been active, so there's no need to check the
conflicts. This is the case the conflicts keyword was originally
designed for.
2. A port that interferes with the build of another port (e.g.
libevent and qt4-mac). If libevent is active while qt4-mac is being
built, qt4-mac fails to build. However it's fine to reactivate
libevent after the qt4-mac build is complete. This type of conflict
needs to be checked even on upgrade, and in fact much earlier than
the install phase when MacPorts currently checks it.
Perhaps we need two keywords to properly handle this, instead of
trying to put both types of problems into the "conflicts" keyword.
Thanks Ryan for a very detailed explanation, it makes perfect sense. I
agree that "conflicts" keyword is overloaded, and for the second case
a separate keyword would work better, like "build-conflicts". Has
anybody requested such feature in ports already?
Thanks, -Kastus
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
