PortGroup directory hierarchy/priority

Rainer Müller raimue at macports.org
Sun Apr 3 03:28:05 PDT 2016


On 2016-04-02 20:48, René J.V. Bertin wrote:
> On Saturday April 02 2016 19:27:38 Rainer Müller wrote:
>> And it would be even more confusing if every single file in _resources
>> used a different strategy.
> 
> Was I proposing that?

As I understood it. Your proposal was to change the lookup strategy for
port groups, which is currently tied to the lookup for all files in
_resources.

>> # sources.conf
>> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>> file:///Users/raimue/unsubmitted-ports
>>
>> Now as soon as a port is added to the official tree my unsubmitted
>> Portfile will no longer be used. Does that mean port groups in
>> unsubmitted-ports would never be used at all?
> 
> Let me return the question: would you be surprised if port groups from the latter were overridden/masked by port groups of the same name in the former (official) tree - just like ports are?
> 
> I guess that typically, if a port comes with a PortGroup for use by other ports that are somehow dependents, you'd commit both the port and the PortGroup.

I only wanted to sketch a scenario where overriding files in _resources
does not apply and a new lookup strategy might not work. I was not only
thinking of port groups.

> I think we agree that there's no need to change anything for the other files in _resources, only for PortGroups.
> Maybe it would become easier conceptually if PortGroups were moved to a different location outside of _resources (preferably only 1 level down from the tree's root)?

Maybe. The point of _resources/port1.0/ is to keep them separate for
each PortSystem. Whether this versioning is necessary is arguable.

The other option would be to properly document how the lookup works for
the files in _resources.

At the beginning of this thread I linked where the PortGroup lookup
happens. So if you have a plan and can work it out, I'll gladly review
any patches.

Rainer


More information about the macports-dev mailing list