Comment 16 for bug 1267393

"Does the MIR/security teams seriously consider pulling all of golang/those static builds into main?"

This issue is quite complicated and slippery. Basically, the decision had been taken in Oakland last November that gccgo is the toolchain Ubuntu Engineering would support on the client and the foundations and security teams don't consider gc supportable from a distro standpoint due to the static linking issue. For the client, promoting golang would mean Ubuntu is not being responsible because we are making all these developers responsible for tracking *our* security and high impact bug fixes. On the client, I don't care if app developers embed some library that we don't provide-- that's on them to keep up to date, but I very much care if we ship a runtime as a standard part of Ubuntu/the SDK that developers are expected to use and we can't provide the fixes for them automatically.

That said, this MIR is about golang in support of juju for server/cloud, but the issue still remains-- we need to make sure we have something supportable. If golang is promoted to main, it is clear to me the Go community would rejoice and use it immediately, but then 3rd party developers will have to track Ubuntu's security fixes and recompile their applications on their own. Sure, we could add a note to the USN that people need to recompile their applications if they use golang, but USNs are not widely read and this practice is far outside the norm for updating stable releases and people will miss the fixes.

To paraphrase Steve Langasek from foundations, if there are blockers for the use of gccgo as the compiler, we should know what those are and we should be fixing those. Personally, my thinking is that if golang is truly the future and what the Go community and Canonical devs want, perhaps we should put resources behind fixing the upstream bug: (which incidentally, doesn't seem to have progressed in a long time).

The foundations and security team's stance is clear: if we ship something in Ubuntu in main, we need to be responsible for it and make sure people can get their updates. Moving forward, I see several options in my personal order of preference:
 1. put resources behind the golang dynamic linking upstream bug and fix it
 2. fix gccgo for the juju use case and/or update gccgo to a new version if one exists
 3. allow golang into main with very strong wording that it is only for juju and that 3rd party developers are on their own

'1' is by far my preferred solution because it would end this once and for all. I don't like '3' and I think it will tarnish Ubuntu's reputation. If we go for '3', a condition of the MIR would be reviewing where we declare the lack of support (an idea I had would be outputting a string at the beginning or end of the compile). Other options may exist, but I know the foundations team looked into them and my understanding is that '1' and '2' are really the only choices.