Testing a modified portgroup

[Fred Wright]

On Mon, 5 Feb 2024, Joshua Root wrote:

> On 5/2/2024 14:58, Austin Ziegler wrote:
>> I think I have found a bug in the golang portgroup, and I think I have an 
>> idea on how to fix it, but I'm not sure how to test such a modification.
>
> You'd make the change in your local copy of the ports tree and check that a 
> port affected by the bug now works correctly, and that some existing ports 
> still work correctly.

That's a nice theory, but it often doesn't work.  A while back, I tried 
doing something of that form, but my change was ignored.  My setup is that 
I have a sparse overlay of the ports tree, containing any locally modified 
files, listed ahead of the normal mirror location in sources.conf.  That 
works fine for testing port changes (as long as the complete directory for 
any modified port is in the overlay), but it didn't work for a PortGroup 
change.  Looking in debug mode, I could see that it was fetching the 
PortGroup from the usual mirror source, rather than from the local 
overlay.  At the time, I just gave up.

Later, I ran across some evidence that it chooses the PortGroup source 
based on the source of the port that's including it.  Since I wasn't 
modifying the including port, that explains the behavior, though it most 
certainly violates the principle of least surprise.  So it may be 
necessary to make a dummy change to the including Portfile to test a 
PortGroup change.

I'm not sure why MacPorts obsesses so much over the location of a Portfile 
rather than its content.  The insanely long build-tree paths differ not 
only based on whether the Portfile is local or not, but also based on 
which particular mirror was used to fetch it in the "published" case. 
Since some build and/or test procedures may choke on the long pathnames, 
and since even the length of the pathname is mirror-dependent, that means 
that in some cases the success of a build and/or test may depend on which 
mirror provided the Portfile.  Sheesh.

Fred Wright