qt4-mac 4.6.2_1 fails to build on G4 PPC
macports at tprfct.net
Sat Mar 20 20:20:43 PDT 2010
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?
More information about the macports-users