Bug 2347543

Summary:	Fedora doesn't provide latest version of Go
Product:	[Fedora] Fedora	Reporter:	Rostislav Krasny <rostigm>
Component:	golang	Assignee:	Alejandro Sáez Morollón <asm>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	41	CC:	amurdaca, asm, go-sig, jcajka, lemenkov, vg.aetera
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rostislav Krasny 2025-02-25 16:47:22 UTC

The latest version of the golang package depends on version of Fedora. Currently this versions matrix looks like the following:

Fedora Rawhide 1.24.0-1.fc43
Fedora 42 1.24.0-1.fc42
Fedora 41 1.23.6-1.fc41
Fedora 40 1.22.12-1.fc40

Fedora seems to have some strange policy and besides patch level updates doesn't provide versions of Go newer than the version that was chosen for the particular Fedora release. For instance I'm using Fedora 41 and I will never get Go 1.24.x before I upgrade it to Fedora 42 that isn't released yet.

This can bring a critical issue that prevents upgrading dependencies of Go projects. For example I can't upgrade dependencies of my project automatically because the newer version of one of its dependencies needs Go >= 1.24.0 that I can't install officially on my Fedora 41, and this is the error that I get:

$ go get -u ./...
go: github.com/ory/client-go.2 requires go >= 1.24.0 (running go 1.23.6; GOTOOLCHAIN=local)

I can run go get -u github.com/ory/client-go.17 now, but what about the rest of the dependencies? I'm blocked and will not be able to upgrade all other dependencies automatically for several months. Upgrading them one by one is very inconvenient.

Fedora 42 is planned for release after about two months from now. But I'm not planing to upgrade my Fedora to version 42 at the day 1 after it will be released, so for me it will happen even later.

On the other hand Fedora provides several versions of Java:

java-1.8.0-openjdk
java-11-openjdk
java-17-openjdk
java-21-openjdk
java-latest-openjdk (OpenJDK 23)

Please do something like that with the golang package. If you go to https://go.dev/dl/ you will see two sets of Go versions that you can download there:

1. Stable versions - currently provides versions 1.24.0 and 1.23.6 of Go
2. Archived versions - provides all older versions of Go

Please provide at least the same stable versions in all supported releases of Fedora. It's much fewer than the bunch of versions of Java that you provides now. I can't wait months for Fedora 42 just to be able to run "go get -u ./..." without a fear of blocking errors like the above.

Reproducible: Always

Comment 1 Alejandro Sáez Morollón 2025-03-12 09:21:47 UTC

Hi! Maintainer of the golang package here.

TL;DR: I have a bunch of ideas to improve this situation.

Although I understand it sounds odd, and it will make my life way more simple, it based on common criteria for every toolchain, for example, this applies to LLVM and GCC too.

I will investigate how we can improve this situation. Your suggestion, although it makes sense, seems a little overkill to me due to the lifespan of Go releases. It's doable, but I wonder if someone will use it. On the other hand, keeping all the versions with the same Go version is massive work because we need to rebuild thousands of packages with each major release. That's in a nutshell, the reason we do it the way we do it.

Meanwhile, as a solution, we (as in the Go SIG) maintain this COPR repository, https://copr.fedorainfracloud.org/coprs/g/go-sig/golang-rawhide/. It will give you the latest version always. I created that repository years ago because this request is not new. I I acknowledge that the discoverability is not as easy as just doing a package search, so that's something I should also improve.