Juju packaging status

[Clint Byrum]

On 2013-04-11 12:20, Mark Ramm wrote:
> 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.
> 


Right, IMO, gccgo is not an option until the go community says it is. 
Lets make go a first class citizen in Ubuntu and learn to deal with the 
static linking consequences.

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

I hate to be Dudley Downer, but the release you speak of is kind of 
already done. I understand that juju is important for Ubuntu's future. 
But We're not just past feature freeze. We are in *final* freeze... The 
thing is releasing in 2 weeks. Let it go, and you'll save a whole lot of 
very busy people a lot of extra work for very little gain.

Just getting python juju in shape to co-exist with the PPA go juju 
package is a huge win.