<br><br><div class="gmail_quote">On Mon, Jun 22, 2009 at 7:55 AM, Joseph Wakeling <span dir="ltr"><<a href="mailto:joseph.wakeling@webdrake.net">joseph.wakeling@webdrake.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Aaron Bentley wrote:<br>
> Maritza Mendez wrote:<br>
>> I understand what you are saying. Requiring bzrtools to test against<br>
>> bzrRC is fine. But we still need a mechanism to help people decide when<br>
>> upgrading makes sense for them. That's what I was really trying to say.<br>
><br>
> Upgrading in what context? If you're using the debs from the PPAs,<br>
> you'll always have a known-good combination. Same if you're using the<br>
> Windows .exe installer.<br>
<br>
</div>Well, the motivation for my original post is that this is not quite so...<br>
<br>
Ubuntu distros contain a number of bzr plugins that are not in the PPA.<br>
In my case that plugin was bzr-rebase, which is recommended (but not<br>
required) by bzr-svn. Upgrading to the latest bzr means upgrading to<br>
the latest bzr-svn, which requires a newer bzr-rebase.<br>
<br>
So, the _strict_ dependencies are met -- there's nothing internally<br>
contradictory between the PPA packages -- but they do clash with other<br>
bzr-related packages in the distro itself.<br>
<br>
The only general solution I can see for this is to mandate that all<br>
bzr-related packages in the distro must also be maintained in the PPA,<br>
which I guess is tricky since the Ubuntu packaging team, the plugin<br>
developers and the core bzr development team would all have to<br>
coordinate around this. (After all, you have no control over what<br>
whacky plugins the Ubuntu devs decide to include in the distro.) But it<br>
does make sense to me to want to define a wider set of core plugins<br>
which will always be packaged in the PPA in versions compatible with the<br>
latest bzr.<br>
<br>
If it's not desirable to have so many plugins in the main PPA then<br>
perhaps there could be a 'use at own risk' bzr-plugins PPA which plugin<br>
developers could upload to independent of the main bzr team ... ?<br>
<br>
</blockquote></div><br>I took Aaron's advice and went back to trusting the PPA's. I really tried. It was less than a day before I found myself driven back into the hard choices Joseph is describing.<br><br>I just keep thinking... bzr cannot be the only project which has faced this challenge. Who are those projects and what can we learn from them? I don't have a good project to offer as a role model yet. But I am sure they exist, because this challenge has nothing to do with bzr especially and should be universal to all projects with active plugin communities.<br>
<br>-M<br><br><br>