PortGroup directory hierarchy/priority

[Clemens Lang]

Hi,

On Sun, Apr 03, 2016 at 01:26:01PM +0200, René J.V. Bertin wrote:
> I tend to view PortGroups as header files, that is files where you
> move variables and code that should be available to more than just the
> port that "goes with" the PortGroup.

PortGroups are not headers, they are just mere include files. You should
see them as code that you would otherwise copy/paste into multiple
Portfiles, nothing more.

> In fact, you could (almost) imagine an implementation where, say, Qt5
> installs its PortGroup in some appropriate place, just like it
> installs Qt headerfiles.

PortGroups cannot be "installed". They need to be there at all times in
the port tree.

> You could even think of such an implementation where the port decides
> whether it installs any PortGroup(s). That should allow for custom
> ports with custom PortGroups that shouldn't apply outside of their
> port tree. I think it would also allow for backward compatibility if
> it keeps a fallback to the current lookup strategy.

Frankly, I don't see the problem with the current method. Just because
you don't like to use SVN during your development doesn't mean that we
should change the implementation.

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:
Enabling a third-party port tree should not give the developers of this
port tree to modify how the main port tree behaves (other than
overriding ports, possibly, but depending on the user's choice in
sources.conf).

-- 
Clemens