PortGroup directory hierarchy/priority

[Rainer Müller]

On 2016-04-04 17:13, René J.V. Bertin wrote:
> On Monday April 04 2016 16:22:27 Rainer Müller wrote:
> This should *not* be the case if the current lookup rules for
> _resources continue to be applied, but a higher priority central
> location (var/macports/sources/PortGroups) is added where copies of
> (symlinks to) PortGroups are installed. In that scenario, foo-1.0
> will only be replaced when the user installs the custom port A.
> Nothing will change if the custom source contains a rogue foo-1.0
> PortGroup that does not belong to a variant of port A, or if that
> custom port A is never installed.

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
breaks reproducibility of *any* operation on a Portfile using this port
group, as the result of parsing may be completely different. In fact,
this might not even define a port with the same name anymore.

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.

>> needed, or the version of the port group could be changed.
> 
> Changing a PortGroup version is a no-go as far as I'm concerned, as
> it makes it impossible to build existing ports against an alternative
> PortGroup without modification.

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.

>> As soon as a port group was overridden for a port we would have to 
>> disable binary archives completely for this port.
> 
> Not necessarily, and in fact that depends more on the associated
> *port* than on the PortGroup. My custom cmake PortGroup for instance
> doesn't introduce any incompatible changes (except possibly for ports
> that happen not to be built as intended with the current PortGroup
> ... but those ports are buggy anyway).