Comment 45 for bug 1267393

Actually, because juju-local only supports one architecture (your local machine), it does *not* download the jujud tools from a remote site, but uses the one on your local machine. (It should be put into the juju-local package, rather than being in the 'juju-core' package, but that is just shuffling the executables around.)

So I think even the local case is already matching what was expected.

The main reason the remote case doesn't just 'apt-get install jujud' on the machines we are starting up, is because that would lead to really out-of-date and fairly incompatible versions of jujud running on a heterogenous system. Having Trusty & Precise machines, would lead to a case where you would only have the jujud that was available on Precise (I'm not even sure if juju-1.0 was available there), mixed with the latest jujud (hopefully 2.0 in Trusty).

It would have been possible to follow the cloud-archive model, where we look up the base Ubuntu image in simplestreams, start an instance with that base image, have that image's first step install a custom archive where we keep compatible versions of the jujud binaries in an archive. However, that doesn't solve the multiple-architectures-that-aren't-Ubuntu case, and we already depend on image lookup.

I *really* feel like there is a clearcut win to separating what is "juju" the client CLI application that you would install on your desktop from "jujud" the server tools that get installed on the machines that are launched. I think "jujud" the binary should be in the juju-local package, and it would make lots of sense to keep "juju-local" in Universe (as it also allows juju-mongodb to stay in Universe, rsyslog-gnutls, cpu-checker, kvm and LXC support can all be brought in by the juju-local package, and *not* by the relatively small juju package.)

I personally think the most productive path forward for Go-in-Ubuntu would be to put effort into the gccgo toolchain, since it is the only one that is going to support PPC/Arm64 anyway. I do think it is a shame to not be using the tool that gets the most focus upstream, but it would fit better into the Ubuntu ecosystem. (We would likely still want to statically compile our jujud binaries, but as they can't really be distributed from the Ubuntu primary archive, I don't think that is particularly problematic.)