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
