No subject

It is just an additional input for the build. Even if the port group is
still compatible, we cannot determine that programmatically. Thus, the
only and safest option would be to disable them altogether as soon as a
PortGroup is overridden.

> In practice, it's what I enforce in my own alternative Qt5 PortGroup,
> but only if the associated port is installed (in that case a variant
> is declared and set default, which doesn't disable binary archives
> but changes the binary requirements to something non-existing).

That sounds quite fragile...

>> binary? What if a ports uses multiple port groups from different
>> trees?
> 
> To repeat myself: don't forget that those trees are usually developed
> by people who use them themselves. If their use-case includes copying
> PortGroups to the main tree, they thus have every interest to protect
> themselves against that kind of eventuality, like I did with the
> aforementioned variant. (I did more in fact; my Qt5 port also tries
> very hard to work with mainstream binary packages of dependent
> ports.)

You might have tried to do that, but if the goal is to make it easier to
plug-in additional external repositories, we have to think of the
generic case.

Rainer