PortGroup directory hierarchy/priority

[Clemens Lang]

On Mon, Apr 04, 2016 at 12:37:05AM +0200, René J.V. Bertin wrote:
> 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.

What kind of information are we talking about here? Compiler flags?
Paths?

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

That would potentially cause ports to build different depending on which
packages you have installed in your environment, which is not
reproducible. The behavior of a port might even be affected by ports
that are not in its transitive dependency tree. Additionally, this could
cause a support burden for us…

"""
 Reporter: Here's this log, the build of A fails.
 Debugger: Cannot reproduce. Your build passes -DFOO, do you have local
           modifications of the port or an overlay of it in the ports tree?
 Reporter: No, the Portfile is pristine and my overlays don't have the
           port… (but a random other port installs an override for a
		   PortGroup that is used by this port).
 Debugger: Closed Won't Fix: Please don't fiddle with our ports and
           report bugs about that.
"""

You might not even be able to get such a bug fixed with the developers
of such a PortGroup, e.g. because the conflict might be between two
non-standard port trees. The more I think about this, the more I get the
impression a PortGroup should only be affecting its port tree, and
nothing else.

-- 
Clemens