#2941 Go 1.19 in Fedora 36
Closed: Accepted a year ago by zbyszek. Opened a year ago by alexsaezm.

Currently, Fedora 36 has Go 1.18 which is going to EOL soon, once the 1.20 is released.

Can we update the version in Fedora 36 to the same one that is in Fedora 37 (1.19) to avoid the EOL?


This was a problem for us in F35, as each Go release had multiple security patches, and it was infeasible to backport every single one. Also, many Go projects only support the last two Go releases, so we were unable to update some applications and libraries. E.g. for moby-engine, there was a security fix that we were unable to promptly ship, because upstream dropped support for Go 1.16.

There was agreement on updating golang amongst the Go SIG, but we'll need an Updates Policy exception to do so.

Metadata Update from @bcotton:
- Issue tagged with: updates policy exception

a year ago

I think I am fine with updating golang to 1.19, it's had enough time to bake in F37 already. One possible problem I see: The Go "Changes" are always scheduled before the mass rebuild, since all go applications need to be rebuilt with the new toolchain to take advantage of it. Is there any way in which updating golang from 1.18 to 1.19 could impact existing go packages in F36?

Doing a mass rebuild in stable branch (maybe even targeted rebuilds of all applications written in Go) is probably not possible - are there any factors which could break these applications if they are not rebuilt? For example, I know that Go applications are statically linked, but does that also apply to the Go standard library?

Oh, additional question: Some packages also started to fail to build with the update from Go 1.18 to 1.19, what will happen to them? Updating Go will make it impossible to ship updates for these packages (unless they have already been fixed for Go 1.19 in Fedora 37+, which some certainly have been, but not all).

oops

Is there any way in which updating golang from 1.18 to 1.19 could impact existing go packages in F36?

Doing a mass rebuild in stable branch (maybe even targeted rebuilds of all applications written in Go) is probably not possible - are there any factors which could break these applications if they are not rebuilt? For example, I know that Go applications are statically linked, but does that also apply to the Go standard library?

I don't think this will be a problem. Go binaries are statically linked, including the standard library. I have tooling to mass rebuild Go applications, so doing so wouldn't be infeasible, but it isn't necessary AFAIK.

Some packages also started to fail to build with the update from Go 1.18 to 1.19, what will happen to them? Updating Go will make it impossible to ship updates for these packages (unless they have already been fixed for Go 1.19 in Fedora 37+, which some certainly have been, but not all).

It's hard to say which packages FTBFS because of the Go update and which FTBFS due to other issues (e.g. incompatible dependency updates) that popped up before the Go update. I'd venture that more updates would be blocked due to upstreams dropping support for older Go versions than the other way around. If packages are broken with newer Go versions, they're probably not getting updated anyways, because people build for rawhide first.

Ok, thanks for the explanation. I haven't been up-to-date with Go stuff lately :) If you think negative fallout will be limited (if any), then it's ok with me. +1

Metadata Update from @zbyszek:
- Issue tagged with: pending announcement

a year ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata