qt4-mac 4.6.2_1 fails to build on G4 PPC

[Ryan Schmidt]

On Mar 20, 2010, at 22:20, Kastus Shchuka wrote:

> 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?

The conflicts keyword is new, so I don't know of any requests that have been made to change its behavior so far.

But I have been thinking we need more granularity in specifying conflicts. Not sure how much, but more than we currently have. I was thinking it should be modeled after how we specify dependencies. That would give us "conflicts_build" for configure- or build-time conflicts (much as "depends_build" is for configure- or build-time dependencies), and maybe rename the current "conflicts" keyword to "conflicts_activate". Each port that uses "conflicts" will then need to be evaluated to see which type of conflict(s) are being specified.

Can anybody think of any other kind of conflict we'd need to specify, or would these two types be enough?