[arch-dev-public] Go 1.17 released - to rebuild or not to rebuild
Yo, I packaged up the new Go release yesterday and moved it over to stable earlier today. Usually new Go minor releases frequently include new compiler improvements and some assorted runtime changes. Previous releases I have done complete rebuilds of Go packages in our repositories but the reception for these rebuilds have been a bit mixed. People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages. But on the other hand I'm not super eager to be alone rebuilding all of this either. So what are peoples thoughts on the subject? Go 1.1 release notes: https://golang.org/doc/go1.17 Previous rebuild: https://archlinux.org/todo/go-116-rebuild/ -- Morten Linderud PGP: 9C02FF419FECBE16
On 2021-08-17 21:36, Morten Linderud via arch-dev-public wrote:
People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages.
What are the relevant "ecosystem changes" in this case? In brief. Have the packaging guidelines been updated for 1.17 considerations? Isn't there a CVE going around in a few projects that re-compiling with 1.17 will automatically catch and fix?
On Sun, Aug 22, 2021 at 12:11:00AM +0300, Caleb Maclennan via arch-dev-public wrote:
On 2021-08-17 21:36, Morten Linderud via arch-dev-public wrote:
People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages.
What are the relevant "ecosystem changes" in this case? In brief. Have the packaging guidelines been updated for 1.17 considerations?
Isn't there a CVE going around in a few projects that re-compiling with 1.17 will automatically catch and fix?
There is at least one fixed CVE in the 1.17 release: https://www.cvedetails.com/cve/CVE-2021-29923/ I have a very mixed opinion about rebuilding the packages. On the hand it is a security vulnerability, hence I would argue for rebuilding them. On the other, It is very toilsome to rebuild all packages depending on Go. Especially, if you consider that we are not doing this for other ecosystems like Rust or GCC (yet). Security before toil, thus we should rebuild them. I am not happy with it, but what alternative do we have? (There are alternatives like building packages via pipelines and signing them automatically, but building that up would need people, know-how and lots of planning)
On 17/08/2021 20:36, Morten Linderud via arch-dev-public wrote:
Yo,
I packaged up the new Go release yesterday and moved it over to stable earlier today.
Usually new Go minor releases frequently include new compiler improvements and some assorted runtime changes. Previous releases I have done complete rebuilds of Go packages in our repositories but the reception for these rebuilds have been a bit mixed.
People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages.
But on the other hand I'm not super eager to be alone rebuilding all of this either. So what are peoples thoughts on the subject?
I'm in favor of rebuilding, just ask foutrelis to spin up his rebuilder and it should be done in no time :) Greetings, Jelle van der Waa
On 8/22/21 12:03, Jelle van der Waa via arch-dev-public wrote:
On 17/08/2021 20:36, Morten Linderud via arch-dev-public wrote:
Yo,
I packaged up the new Go release yesterday and moved it over to stable earlier today.
Usually new Go minor releases frequently include new compiler improvements and some assorted runtime changes. Previous releases I have done complete rebuilds of Go packages in our repositories but the reception for these rebuilds have been a bit mixed.
People do not really see the need to rebuild $goWorld when packages a compiled and nothing inherently breaks unless there is a rebuild. We don't do this for GCC, Rust and so on. However I do think it's nice to group up these ecosystem changes in one swoop as it spares me from having to repeat myself for the next few months as people occasionally update their Go packages.
But on the other hand I'm not super eager to be alone rebuilding all of this either. So what are peoples thoughts on the subject?
I'm in favor of rebuilding, just ask foutrelis to spin up his rebuilder and it should be done in no time :)
Greetings,
Jelle van der Waa
As far as i see this has not yet happened but people were for it and nobody objected -- can we make it happen? cheers, Levente
participants (5)
-
Caleb Maclennan
-
Christian Rebischke
-
Jelle van der Waa
-
Levente Polyak
-
Morten Linderud