#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