maintainer-feedback requested: [Bug 285952] lang/go: Re-evaluate our approach

Bugzilla Automation <bugzilla@FreeBSD.org> has asked Golang Team (Nobody)
<go@FreeBSD.org> for maintainer-feedback:
Bug 285952: lang/go: Re-evaluate our approach
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285952



--- Description ---
Cc'ing portmgr because from what I can tell, there isn't really a go team right
now and I need big-picture thoughts.

Go 1.21 overhauled how go ports are built, and we didn't really adapt, so
things are building unpredictably right now.

Under the new system, the go.mod file can specify the toolchain, like:
go.mod:
  go 1.22

What happens next depends on which toolchain version we're using:
< 1.22: The 1.22 sources will be extracted and built, and then those new
libraries will be used to compile the binary.

>= 1.22: It will build using the installed toolchain, BUT no features newer
than 1.22 will be used.

Go's backwards compatibility explicitly guarantees that this will always be
true: go 1.1000 knows about and will be able to build against 1.22 features.


The long and short of this is that it doesn't really make sense to keep
multiple versions of go anymore. The latest version will always be able to
build older ports (and similarly, older toolchains should in general always be
able to build newer ports).

I'd like to propose the following:
1) Remove all versioned go ports, and go back to simply lang/go
2) Remove DEFAULT_VERSIONS support for go
3) Change the semantics of USES=go:1.22 so that it sets GOTOOLCHAIN=go1.22 to
force a build using 1.22 features.


Regarding #3: really old ports that won't build with newer go need a way to pin
the toolchain. We can forcibly pin using GOTOOLCHAIN=go1.22.


Portmgr: Does this approach make sense? What am I overlooking?