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 will try then to explore how to create a compat package; the last thing I want is to make maintainers work more because of this. > best regards > > Brad > > On Thu, Nov 6, 2025 at 5:29 AM Alejandro Sáez Morollón <[email protected]> > wrote: > > > > On 2025-11-06 12:11, Fabio Valentini wrote: > > > On Wed, Nov 5, 2025 at 8:30 AM Alejandro Sáez Morollón <[email protected]> > wrote: > > >> > > > > > > (snip) > > > > > > Thank you for working on this! > > > > > >> TL;DR: Yes, they would have upgrades, but we might only have 2~3 > compat > > >> packages at a given time, and I, personally, think it adds more > complexity. > > > > > > I agree, this seems to just be a complicated middle ground between the > > > current status quo (major Go update pushed to stable branch) and fully > > > versioned packages, with the downsides of both, but with the > > > advantages of neither. > > > > > > And while I can see the argument that pushing major version updates > > > for Go to stable branches can cause unintended breakage and churn, I > > > don't think this would be a big problem in practice. And I assume that > > > *if* a change to the update cycle for golang like this were > > > implemented, the update would still land in rawhide *first*, then sit > > > there for a while (weeks? months?) until all problems have been > > > resolved, and *only then* merged to stable branches? > > > > > > Fabio > > > > That's right. Maybe it was not clear in my initial mail, but I am not > > trying to remove in any way the workflow. Every new major release would > > land on Rawhide first, build there, and then move into the other > > releases. Similar to what we have right now but targeting more branches. > > > > Also, I intend to use mass-prebuild [0] before even pushing to Rawhide. > > It's something that I should do no matter the outcome of the proposal, > > as I hit/created last-minute issues in the previous two Fedora releases. > > I played with the tool recently, and I really like it. > > > > As far as I know, we can't run it as part of the CI, but the state of > > the packages will appear in COPR and I can always link it to the PRs for > > everyone to see. > > > > [0] https://packages.fedoraproject.org/pkgs/mass-prebuild/mass-prebuild/ > > > > -- > > _______________________________________________ > > 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 > -- > _______________________________________________ > 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 >
-- _______________________________________________ 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
