PortGroup directory hierarchy/priority

[René J.V. Bertin]

On Sunday April 03 2016 18:26:53 René J.V. Bertin wrote:

> >In fact, I'd argue that a PortGroup should only ever be allowed to
> >influence the ports in its port tree. The rationale for this is trust:

There's another point I hadn't considered yet because I only have custom PortGroups that I actually use and also make sure that I don't introduce changes of behaviour when the corresponding local ports aren't actually installed.

Take a custom version of a port "foo" which has a corresponding PortGroup "foo". That PortGroup contains information foo's dependents require, and that is not identical between the custom and default port:foo.
A user can install the port tree containing that port,PortGroup combination for other reasons, and not install the custom port:foo. In that case, the custom foo PortGroup should be ignored, but when the custom port:foo is installed any port from the main port tree that depends on "foo" should use the appropriate PortGroup.

As I said, I didn't consider this scenario until now, but my idea of an additional central, higher-priority location for PortGroup files that holds copies of or symlinks to the files in a _resources directory does allow for such a scenario.

I like this idea (not just because it's mine). Whether or not a custom PortGroup overrides the mainstream version becomes a user choice without need for an additional setting, and only for ports that actually need their PortGroup to apply globally. You can use symlinks so it's trivial to check which PortGroup is being used. If you reactivate the mainstream (or the custom) version of the corresponding port, the PortGroup is switched accordingly because it's part of the installed files.
And all it takes is a small change to the PortGroup lookup strategy where the central location is checked first, plus optionally a convenience procedure that copy or symlink the required file(s) or simply the equivalent of the ${filespath} variable.

R