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

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 14 May 2026 16:47:21 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295287

            Bug ID: 295287
           Summary: lang/go125+: building in "legacy" mode should still be
                    supported
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: go@FreeBSD.org
          Reporter: freebsd@dev.thsi.be
          Assignee: go@FreeBSD.org
             Flags: maintainer-feedback?(go@FreeBSD.org)

Created attachment 270729
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=270729&action=edit
0001-lang-go-GO_NO_VENDOR_CHECKS-extended-for-go-1.25.patch

Hi,

Apologies if I have missed the notice that building go packages in
"legacy"(*) mode isn't supported anymore, but it appears that since go
1.25 the method described in the porter handbook "6.6.8. Building Go
Applications" is broken(**).

The attached patch restore the support for lang/go125 and
lang/go126. Please be aware that I'm not a go guru so a second look
would probably be desirable, but at least it allows me to build
packages that used to build just fine with an older go versions.

If the plan was indeed to remove supporting the legacy mode (a plan
that I would personally find inconvenient), then I'd suggest removing
the broken patches of lang/go125 and lang/go126, removing
ports-mgmt/modules2tuple from the tree, cleaning up Mk/Uses/go.mk and
updating the porter handbook accordingly, or simply adding a
clarifying note as to avoid any more confusion.


Thanks,

Benjamin

*: that is having USES+=go:modules and no GO_MODULE set, per my
   interpretation of Mk/Uses/go.mk. Note that the "Legacy" comment
   actually covers the broader case where USES=go:modules could also
   be absent but since this would preclude the definition of
   GO_NO_VENDOR_CHECKS environment variable, I concluded that there are
   now in fact two kind of legacies: an oldest without go:modules and
   one without GO_MODULE.

**: see, e.g.,
https://forums.freebsd.org/threads/poudriere-go-modules-and-ght_tuple-issues-with-custom-build-script.101851/

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