PortGroup directory hierarchy/priority

[René J.V. Bertin]

On Sunday April 03 2016 14:47:35 Clemens Lang wrote:

Hi,

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

Forgive this self-taught programmer, but that's exactly how I see header files (and, indeed, PortGroups).

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

Dang, I hadn't thought of that yet.
That doesn't exclude the possibility of an additional installation of a copy into a place with higher priority, though.

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

This is not just about me. I've already indicated that I have my own solution to the issue. I do have a growing number of "users" of my port tree though, often newcomers to MacPorts, who are motivated enough to jump through a number of hoops in order to get access working KF5 ports. 

The problem is evident from your own words, IMHO, where PortGroups are "mere include files" that contain "code that you would otherwise copy/paste into multiple Portfiles, nothing more". That "nothing more" doesn't suggest that whether or not you're supposed/allowed to paste into a given Portfile depends on its location. I know of no "mere include files" that are available only to source files sharing a common root either. 

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

Well, then introduce a setting in sources.conf that allows users to make PortGroups behave like ports. Or a ${prefix}/var/macports/PortGroup directory that's used as the first place to look up these files, along with a big fat warning when a port installs something in there as well as one in main.log when a PortGroup is taken from there.
Let's face it: it's probably not at all impossible for any port to replace files in the main port tree, which I'd agree is a far worse evil (but one I might well end up implementing).

In the meantime I'm going to put big fact warnings in the post-activate of those of my ports that are affected by this issue.

R