In D50595#1155305, @mengzhuo1203_gmail.com wrote:

Thanks for review,
This change only affect download source code and binary for go itself.
The https://golang.org/dl/*.src.tar.gz redirect (HTTP 301) to go.dev/dl then Google blob file server.

Other golang.org namespace library (golang.org/x) won't change AFAIK.

Good catch! I'm definitely in favor of switching, but:

In D49906#1153054, @kbowling wrote:

Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.

In D49906#1152227, @fuz wrote:

The best way would be to set GOTOOLCHAIN=local when building Go ports, which disables the “fetch the appropriate toolchain” mechanism. This makes it impossible to build Go ports requiring too new toolchains, but then perhaps there's more of an incentive to have them packaged quickly.

In D49906#1151683, @fuz wrote:

If the test build shows that none of the ports fail with a more recent toolchain, I'm okay with only providing it. But what we must disable in the ports tree is the mechanism where Go tries to download a newer toolchain if it considers itself outdated. Downloading random toolchains at fetch time is not what we should be doing.

So, I should have tagged this review in the commit, but I set go124 as the default as portmgr/pkgmgr seems to be swamped at the moment. Once we see how things build, we'll have a better picture of whether this will be a viable thing.

In D49906#1138522, @fuz wrote:

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.

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.

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.

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

This is a good approach. I'm 👍 on behalf of the go team.