[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
John A Meinel
john at arbash-meinel.com
Wed Apr 2 05:38:11 UTC 2014
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.)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions
More information about the Ubuntu-server-bugs
mailing list