[Bug 295287] lang/go125+: building in "legacy" mode should still be supported

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 15 May 2026 11:07:09 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295287

--- Comment #2 from Benjamin Jacobs <freebsd@dev.thsi.be> ---
Hello,

Thanks for your reply. And my bad, I have wrongly inferred that go
1.25 changed something because I saw the same errors as in the forum
post ("go: inconsistent vendoring package@ver: is explicitly required
in go.mod, but not marked as explicit in vendor/modules.txt"). I
confirm that go 1.22 and 1.24 give the same result (by copying
lang/{go122,go124,go-devel} from 2026Q1 and setting the
DEFAULT_VERSION). So I guess that I can close this PR.

I'm trying to update an old port that I had laying around to the the
tip of their github repo, so I could be doing something stupid
(go:modules + GH_TUPLE + GH_TAGNAME) and/or there could be some funcky
stuffs in the upstream repo.

The go:modules + GH_TUPLE combo is documented in the PHB right after
the GO_MODULE paragraph. I struggled a bit to fix the tuples2modules
ouput and to make (what I believe are) the right adjustements in
post-extract, as it seems that modules2tuple doesn't support version
tags having '/' in them and other stuffs that packages do nowaday
(unduplicate some repo and adding some symlinks, mangle some /vx
suffixes, etc).

Also I end up with a symlink loop in work/portname-hash/portname-hash,
I can't figure out what creates it, but this doesn't seem to impact
the go errors that I get. I tried simply using "USES=go" as you
recommend, but that too fails in a completly different way. It is
funny that I could have it working by patching the go compiler in the
most uneducated way :D Although the patch seems to do what is wanted:
not bothering checking the (inexistent) vendor/modules.txt

I tried to use a GO_MODULE=github/account/project@sha1, but that too
seems unsupported. Maybe I should try to set GO_MOD_DIST to the raw
github url instead?

I think that I'll live with the go patch for now, and I may revisit
when/if I get the interest again and that the project tags a new
version. I just really want to test the last in-development changes.
There might be issues with the current state of the upstream repo too,
I'd be unable to tell...

I'm attaching the port in question for reference. An old version that
works (using go:modules + GH_TUPLES) and my attempt to use a
GH_TAGNAME that works with attached patch to lang/go*. If you see
something obvious that would be welcome, if not I'll live with that :)

Cheers,

Benjamin

-- 
You are receiving this mail because:
You are the assignee for the bug.