PortGroup directory hierarchy/priority

[René J.V. Bertin]

On Monday April 04 2016 17:59:11 Rainer Müller wrote:

> As Clemens said, PortGroups need to be available to parse a port. They
> cannot be installed with a port. You would have to keep one version in
> the ports tree and then another one that is installed by a port. That

Yes, that's what I am now thinking of.

> Your case with a custom port group providing an additional variant seems
> so special that I doubt it is really worth or possible to develop a
> generic solution.

Where did I say that the additional variant was in any way central to my suggestions?

> As a PortGroup is merely an include, changing the port group means
> changing the Portfile. As the input for parsing the Portfile changes,
> this would still be a modified port.

I'm not going to bother replying to that ...

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

Sure, you can unset the variant explicitly if you're feeling adventurous. I guess I could check against that ([variant_exists qt5kde] && ![variant_isset qt5kde]) and someone even more adventurous could remove that check.
I don't think of that as fragile, but as "not foolproof". 

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

True enough, but also excludes all the border cases where things could go wrong. The generic case is one that has a committed developer behind it, who uses his own stuff and realises that promoting his repository comes with responsibilities. No one has any control over that of course, but well, we are already in that situation.

R.