On Fri, Nov 28, 2025 at 6:31 PM Florian Weimer <[email protected]> wrote:
> * Alejandro Saez Morollon: > > > On Thu, Nov 6, 2025 at 4:33 PM Brad Smith <[email protected]> > wrote: > > > >> I recently ran across a problem when revising the Kubernetes 1.34 rpm > >> spec file. I was testing the revised rpms in a VM by creating a > >> cluster using kubeadm. > >> > >> The rpms in the Fedora repositories were built with go 1.24 and worked > >> as expected. The revised rpms were built with go 1.25 and kubeadm > >> failed with an unexpected error (see > >> https://github.com/kubernetes/kubernetes/issues/135013 for error > >> details if interested). > >> > >> In the discussion with the Kubernetes team they determined that yes > >> there is a bug in the code with go 1.25 (and go 1.24.8+) and that a > >> fix is in place and will be included in the next release (11 Nov more > >> or less). But they were also specific that they expect distributions > >> to build Kubernetes with the version of Go they explicitly build with > >> - in this case Kubernetes 1.34 is built with go 1.24. Their makefile > >> is structured to download the correct version of Go if not present on > >> the build machine. They cannot guarantee that Kubernetes built with a > >> newer version (at the minor level) will function correctly. To > >> paraphrase their comment - there is a tight coupling between a > >> Kubernetes version and a Go version. > >> > >> Fedora rawhide (f44) and F43 now use Go 1.25 which means I have to > >> consider whether or not to continue releasing Kubernetes updates for > >> these Fedora releases. Past record suggests that this is a rare > >> problem but as noted above it can occur. > > > > Let me excuse myself first because of the delayed answer. > > > > This is a good counterargument example. So having a compat package > > would have made your life easier, right? Because you could have > > pointed to golang1.24 and called it a day. > > I think what would have been needed is a golang1.24.7 compat package—the > bug is present in 1.24.8 and later per Brad's message. > > Per the upstream issue, one has to use exactly the specified Go minor > version. > > Not sure if this is something that Fedora wants to support in general. > (There was an approved change proposal to adopt upstream toolchain > choices, and even though the example quoted where of the form, “use this > specific compiler binary”, that was not the Fedora proposal.) > > Oh, you are right; in this very specific case, a simple update in golang1.24 would have broken the update too. We had in the past scenarios where the problem was between major releases, but Brad's case is very specific. I really never thought about minor releases of compatibility packages. That would be really difficult, and the number of people using them would be extremely low. I wonder if creating one for exceptional cases like this could be possible regardless of what solution we do. > Thanks, > Florian > >
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
