juju-deployer fails because of juju's binary renaming

[Chris Glass]

the juju project decided to rename the /usr/bin/juju binary to /usr/bin/juju-1.

After the switch, juju-deployer is no longer functional, since it explicitely looks for "juju" as the executable name.

[David Britton (dpb)]

xenial 1.25.5 packages removed the 'update-alternatives' mechanism that the 2.0 support was relying on to work.

[David Britton (dpb)]

Note in trusty, the packaging still appears to be OK:

(Reading database ... 162391 files and directories currently installed.)
Preparing to unpack .../juju-core_1.25.5-0ubuntu1~14.04.2~juju1_amd64.deb ...
Unpacking juju-core (1.25.5-0ubuntu1~14.04.2~juju1) over (1.25.3-0ubuntu1~14.04.1~juju1) ...
Setting up juju-core (1.25.5-0ubuntu1~14.04.2~juju1) ...
update-alternatives: using /usr/lib/juju-1.25.5/bin/juju to provide /usr/bin/juju (juju) in auto mode

[Stuart Bishop (stub)]

Adding /var/lib/juju-X.XX/bin to the start of the PATH before invoking juju-deployer should be the easiest work around.

Longer term, if you invoke juju-deployer as a plugin ('juju deployer ...' rather than 'juju-deployer'), then this becomes Bug #1567296. This is probably nicer than juju-deployer specific mechanisms for specifying the correct juju binary to use?

[Nicholas Skaggs (nskaggs)]

This has been made simple to fix in xenial. SImply install the juju-1-default package.

sudo apt-get install juju-1-default

It will set /usr/bin/juju to point to juju-1 again for as long as it is installed.

[David Britton (dpb)]

With the new juju-1-default package in xenial, I don't see a reason to address this further.

[Stuart Bishop (stub)]

Per Bug #1567296, I think the way forward is to invoke the tool as 'juju-1 deployer' (as a plugin) rather than 'juju-deployer' (as a script), which will make the juju-1-default package unnecessary.