Juju packaging status

[Mark Ramm]

On Thu 11 Apr 2013 01:16:10 PM EST, Martin Packman wrote:
> An update on where we are with packaging juju for raring.
>
> The overall plan is to have:
>      juju-0.7 as the binary package for python juju
>          installs binaries, manpages, and so on to versioned directories
>          uses update-alternatives to symlink into the normal locations
>      juju as a metapackage
>          requires juju-0.7 as python juju expects this machines install
> from distro
>      juju-? as the binary package for go juju
>          currently is juju-core, but we probably want a version here instead
>          also uses update-alternatives to symlink to same locations
>
> This then allows us to migrate users reasonably easily in future. As
> environments are not cross-compatible, the main goal is simply to make
> it painless to have both sets of client tools installed.
>
> The python juju work is basically done. Had review on new python juju
> release and packaging changes, including update-alternatives work by
> Mark:
> <https://code.launchpad.net/~gz/ubuntu/raring/juju/0.7/+merge/158088>
>
> Applied for a feature freeze exception for including in raring:
> <https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1167921>
>
> The go juju packaging changes for co-installability are available in
> Mark's branch:
> <https://code.launchpad.net/~mark-mims/juju-core/packaging-with-alternatives>
>
> What we have left to resolve seem to be open questions about how we
> should be packaging go applications in ubuntu. The current go
> packaging doesn't build with the standard process, it expects several
> source branches to be included as per the recipe:
> <https://code.launchpad.net/~dave-cheney/+recipe/juju-core>
>
> What should be be doing instead? Separate debian packaging for each go
> source dependency does not seem practical at present. Daviey asked
> earlier about using gccgo to avoid the static linking issue, which
> none of the juju team have been testing with, so does not seem like it
> would improve quality at present.

Given lack of real world testing of Juju when built with gccgo, and 
given that we have no experience at all with gccgo in production, I am 
wary of making a change at this time.  I think this is a good thing to 
discuss for the future, but not something that is realistically 
achievable today.

> Given the limited time we have to resolve this, it seems we either
> need help from the server team to bring the go juju package into a
> state that ubuntu developers can live with for this release, or will
> should reevaluate what we're including in the archive for raring.

Agreed, and we will have to see what those objections are, and we 
should then re-evaluate what needs to be done based on that feedback.   
Hopefully we will be able to find a reasonable approach that gets this 
into the release.   I think the only realistic fallback if we have to 
do gccgo given time-lines would be not to include the actual juju-core 
package into raring and just use the ~juju ppa.

> Daviey kindly offered to review any package we propose this week, but
> I feel neither Dave or I have the expertise to resolve the outstanding
> issues.

Sounds like what we need is a prioritized list of things that "need 
fixing" , and then we can figure out how to try to get that done. I'll 
ping people and see if we get some kind of gap analysis, so we can 
figure out a plan

--Mark Ramm