lang/go: Provide only one go version

[adamw]

Summary

The ultimate goal here is to drop down to providing one version of Go.

It should essentially be a NOOP; depending on the go value in go.mod, Go will already download and add packages for a newer version, and will restrict itself to features present in an older version.

There's really no value anymore in providing old versions of Go. Someday a go-devel could get created, but that's essentially going to be it.

I'm starting with a patch that just forces 1.24 as the version for everything. If things look fine, then I'll rip out go.mk's guts and do some smaller follow-up testing.

[adamw]

@danilo are you able to please test build all the go ports?

[kbowling]

Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.

[adamw]

In D49906#1137925, @kbowling wrote:

Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.

The point is that Go now builds the same regardless of which version you use. If the go.mod says to use a newer version, it builds the stdlib from that version and links it in. And if go.mod says to use an older version, go restricts its feature set to behave exactly as that old version would.

So, whether we have one Go version in the tree or ten, the output will be exactly the same. There's literally no difference between Go versions anymore, so we gain nothing by having multiple in the tree.

[kbowling]

In D49906#1137930, @adamw wrote:

In D49906#1137925, @kbowling wrote:

Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.

The point is that Go now builds the same regardless of which version you use. If the go.mod says to use a newer version, it builds the stdlib from that version and links it in. And if go.mod says to use an older version, go restricts its feature set to behave exactly as that old version would.

So, whether we have one Go version in the tree or ten, the output will be exactly the same. There's literally no difference between Go versions anymore, so we gain nothing by having multiple in the tree.

Ok, I'm tracking on the backward compat. Although I am skeptical about the last sentence, i.e. we will need an equal or newer compiler to handle all go.mod versions. But that is a tractable situation. And exp-runs will shake out anything that is not adequately pinned.

[adamw]

In D49906#1138150, @kbowling wrote:

In D49906#1137930, @adamw wrote:

There's literally no difference between Go versions anymore, so we gain nothing by having multiple in the tree.

Ok, I'm tracking on the backward compat. Although I am skeptical about the last sentence, i.e. we will need an equal or newer compiler to handle all go.mod versions.

I know... I have some skepticism too, though this is how Go says it's supposed to work. I'm curious to see what that exp-run looks like too!

But: new shouldn't matter either (in theory), because if you have 1.22 and go.mod says 1.24, Go will download, compile, and link in the newer toolchain.

Go definitely behaving in a well-reasoned and polite manner, but it's just completely contrary to how the ports tree expects builders to behave.

[dbaio]

@adamw I've just opened an exp-run request on 286214.

[fuz]

I disagree with this step.

We should instead disable the feature where Go tried to download a toolchain and have Go err out instead. This can be achieved by setting GOTOOLCHAIN=local in the environment. Packages should always be built with our own toolchain, not the one provided by Google. The downloaded toolchain has none of our site patches, is outside of our control and we don't do this sort of thing anywhere else.

Please also consider that there are ports which don't build with a newer Go version. While rare, this occasionally happens and may require using an older than the default toolchain.