PortGroup file resolving.

[RJVB (René Bertin)]

I think there's an issue with the way PortGroup files are searched (resolved). Take a port tree configuration like mine (from sources.conf:

file:///A [nosync]
rsync://rsync.macports.org/release/ports/ [default]
file:///B

It seems that a statement PortGroup qt4 1.0 from a Portfile under /A or /B makes "base" do a search for a file called qt4-1.0.tcl that looks first in _resources/port1.0/group under /A or /B respectively. If the file doesn't exist there, it is read from the default port tree. This also means that ports that have their Portfile under the default tree will not use the PortGroup file from /A but from their own tree instead. One thus cannot develop a new PortGroup file in a local repository like /A, instead, one has to copy it to the default tree after each selfupdate.

I consider that a bug because Portfile resolving does not function the same way. Ports that exist in /A override identically named ports in the default tree, which override those in /B, and selfupdates do not interfere with this. I think PortGroup files should be resolved that same way. Note also that build failures that result from the selfupdate replacement of a PortGroup file with the current release version are not necessarily easy to debug, and that such a replacement can also lead to runtime errors instead of build time errors.

I've asked about this on macports-devel, don't recall having ever had an answer, so I'm raising it as a ticket on here.

[ryandesign (Ryan Carsten Schmidt)]

I also came to the conclusion some months ago that one could not develop portgroups anywhere but the main ports tree.

[dliessi (Davide Liessi)]

Cc Me!

[raimue (Rainer Müller)]

​https://lists.macosforge.org/pipermail/macports-dev/2016-April/032733.html