Comment 28 for bug 1267393

I wrote this before:

"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.
"

In light of my comment #27, I still consider '2' most correct and '1' is interesting but I don't think either is a requirement anymore so long as we define sane embedding policies (ie, don't allow it) and agree that we can provide updates in a manner resembling what I described in comment #27.

I'll let Seth comment on the security review for juju-core. Others have commented on the "installer package" issue.

Assuming those issues are addressed, I have this to say:
* juju: conditional ACK provided we pull out the embedded copies and push them into golang-*-dev packages. If this is not feasible for 14.04, we may be able to defer this to 14.10 (after all, juju will be the only Go package in main so it doesn't really matter where the libraries are for one package)
* golang: conditional ACK provided packaging policy, support procedures and MIR standards conversations are started (I don't expect these to be resolved by 14.04)