PortGroup directory hierarchy/priority

[René J.V. Bertin]

Hi,

After discussion with a MacPorts "newby" who was motivated to use my ports tree (to get at the KF5 ports), I clarified the instructions in my README:

{{{
Ports that are in my repository but are also in the default repository will override those in the default repository (and all other repositories listed after site-ports in sources.conf). If you use the aforementioned [nosync] option, you'll have to update the tree yourself. In that case you may have to do `portindex -f` at least periodically, to account for changes like removed variants or subports.

An important note: this repository also contains PortGroup files. These files that contain definitions that are used by multiple ports that share certain properties (form a group, say all ports that build using CMake, or that use Qt or KDE libraries). PortGroups are like C header files, or Python/Perl/Tcl packages, included via a specific command in a port's "Portfile". Note that PortGroups themselves can include other PortGroups in exactly the same way! An example: the command `PortGroup kf5 1.1` will include the file kf5-1.1.tcl, which will then include other PortGroup files like qt5-1.0.tcl, qt5-kde-1.0.tcl and cmake-1.0.tcl. Each file will be included from either the same _resources directory, or else from the default _resources directory.
These PortGroups apply only to the ports in the local repository. This may lead to surprising behaviour and errors. For instance, if you install my port:qt5-kde or port:qt5-kde-devel, every port (including those in the official port tree) that requires Qt5 will need to use the corresponding Qt5 PortGroup (the qt5-*1.0.tcl files and probably qmake5-1.0.tcl), esp. if you plan to build them from source.
You will thus have to copy the corresponding files from the /opt/local/site-ports/_resources directory to the same directory in the default port tree (defined in sources.conf). You will have to do this again after each selfupdate.
Sadly there isn't much that can be done at the moment to make this more convenient. The best rule of thumb is to check for each port you install from my tree what PortGroups it uses (fgrep PortGroup `port file foo`), identify the corresponding files and files those include, check which ones are present in site-ports/_resources, and copy those files to the default _resources directory.
}}}

I thought it might be useful to cite that text here.

It also made me wonder if we couldn't come up with an alternative to changing the lookup strategy in "base". As mentioned, there is currently no assistance whatsoever to determine what PortGroups might have to be copied, and of course the source and destination directories aren't exactly trivial to find either. That makes the task a bit daunting for people unfamiliar with MacPorts and esp. if they're not experienced terminal users.
How about a mechanism akin to `port select`, in which a port can declare which PortGroup files it uses and needs to be made available outside the local port tree. That information can be defined in the Portfile (as an installable file) or else in a separate file in the port dir, and could be used via a specific command (e.g. provided by a port with convenience utilities for using custom port trees). An initial implementation could simply take care of copying the required PortGroups (and register a reminder to be printed after each selfupdate). A slicker implementation would maintain a lookup table for the concerned PortGroups, meaning only those are handled differently and all others keep following the current lookup strategy.

Then again all this seems overkill to me. I really cannot come up with a valid scenario in which you'd want a PortGroup to be confined to its local tree. If a local (custom) port needs to override a global PortGroup for some reason it can simply use one that has a different name or version (one not used by any global port; I presume the version is simply a string and doesn't have to be numeric so one could do something like `PortGroup qt5 private`).
Am I missing something that should be evident?

R.