Comment 29 for bug 1267393

> * We figure out how to have a reasonable support story using golang-go. One
> idea is that we could consider automatically performing no-change uploads to
> -proposed with some bug automation if we update the runtime in an SRU/security
> update. All packages in main are supposed to have a team subscribed to them,
> so that team would be responsible for verifying the package in -proposed.
> This seems to be in the spirit of Go development-- teams choosing to use Go
> are responsible for recompiling and retesting and a team's choice of Go will
> have to consider this cost.

No-change uploads in response to a security update in a depended-on go library package addresses the problem of making sure the security updates happen, but it's still a suboptimal delivery method for those security updates because of the download size. Instead of pushing an update for just the library with the security fix, you're pushing the update for that package plus all its reverse-dependencies, which is made all the worse by the fact that each of those revdeps is statically linked (==larger). We might be able to make this work for juju in the short term, but it doesn't scale particularly well.

> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.

If we were to implement this at all, we should leverage the Build-Using field as defined in Debian policy.

> Developers may of course choose to use gccgo, but my current thinking is that
> based on various conversations with Go developers, efforts to improve
> gccgo might be better spent making golang-go supportable and this necessarily
> means stretching our existing policies and processes.

My biggest concern here is that making golang-go genuinely supportable in the distro context means supporting dynamic linking, and the Go upstream community appears to be quite hostile to the principle of dynamic linking. So I'm not sure this is actually the path of least resistance - unless you are suggesting that we compromise our standards for main over the long term by doing the reverse-build-dep rebuilds you described.