[MacPorts] #47441: PortGroup file resolving.

[MacPorts]

#47441: PortGroup file resolving.
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  base         |    Version:
 Keywords:               |       Port:
-------------------------+--------------------------------
 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/47441>
MacPorts <https://www.macports.org/>
Ports system for OS X