[Oneiric-Foundations-Topic] networked client app updates

Allison Randal allison at canonical.com
Tue Apr 26 23:29:32 UTC 2011

On 04/26/2011 11:53 AM, James Westby wrote:
> On Thu, 21 Apr 2011 18:23:52 +0100, John Rowland Lenton <john.lenton at canonical.com> wrote:
>> * if our projects switch to, say, python 4, then we'd be looking at
>>   shipping python 4 to all supported ubuntus, including LTS'es.
> I can see why you would want to do this for ease of support, but it's
> common for projects to support several versions to avoid this
> requirement.
> In addition, making a change like this would likely have effects far
> beyond u1, in order to allow u1-on-lts to use a Python version that may
> not have been available when it was released.

This is where the /opt/.../UbuntuOne/... install location comes into
play for dependencies. Simply using backports means the updated
library/tool affects the entire system, which is likely to be a
nightmare. Installing a version in /opt, which only one app can find, is

My gut reaction is that installs of dependencies in /opt should be very
rare, and paved with warnings to the app developers of "You understand
that you are *personally* responsible for this version of the library
you're installing with your app? And it darn well better not leak out
into the rest of the system!" But, it does fit with general Linux
development practices in the wider world.

>> * it's easy to imagine scenarios where we'd want to ship updated
>>   versions of rhythmbox, banshee or nautilus (and/or any newer
>>   application that integrated with our apis). Much more commonly we'd
>>   want to update plugins to those apps.
> Why would you want to upgrade the apps themselves?
> This seems to be getting away from what I thought was the original
> question in the discussion, and in to the more general territory of
> wanting to push new stuff in to released versions, and perhaps it is
> worthwhile to separate those discussions if possible?

This is a cost/benefit question. Chances are it's very expensive to do
the integration and maintenance work on non-standard versions of all
those apps, and much less expensive to maintain multiple variants of the
plugins. But, it's appropriate to consider the problem on both sides as
we work our way toward the best solution.

>> the thing we need is to have as much feature parity as is possible
>> across all the platforms we support,
> This seems to be a core point of contention. Perhaps you could explain
> why feature parity across versions of Ubuntu is important to your team.
> As I understood the original question it was how to update client code
> to keep it in sync with changes that the server makes. It would be
> possible to do that in order to keep old features working and not enable
> new features on the old releases. A desire to push new features in to
> old releases is valid, but seems to be a different question to me, and
> not one that has a lot to do with the code in question being a networked
> service client.

The key feature of a lightweight client app like this is "the ability to
connect to the remote service". It is possible to maintain 5 versions of
U1 client that each implement the latest connective features, but depend
on only the versions of various libraries/tools available in each
supported distribution. That's one for (to take a snapshot today):

- Natty, the upcoming release
- Maverick, the current release
- Karmic, the soon-to-be-removed non-LTS release
- Lucid, the current LTS release
- Hardy, the soon-to-be-removed LTS release

And, it might even be reasonable to ask the U1 team to continue with
this rather hefty maintenance burden perpetually, since they happen to
be backed by a company that deeply believes in the Ubuntu release cycle.
I'm not so sure it's reasonable to ask other developers of other
networked client apps to carry similar maintenance burdens. Or at least,
we can ask them to, but they're perfectly free to say "No thanks, we
just won't bother with an Ubuntu version". Or, they'll do what Dropbox
does, and just maintain their own "pirate radio" repository just for
their client app, completely avoiding the standards and quality control
Ubuntu has in place for repositories.

That's not necessarily a bad thing, there's always room for the chaos of
evolution. But, the fact that we have multiple projects all stumbling
around the same problem also means this is an opportunity to be
opinionated, solve the problem once in a way that really fits with
Ubuntu, and set an example in U1 for the best way to implement updates
for a networked client app on Ubuntu. There are definite advantages to a
clean set of thoughtfully developed standards.


More information about the Ubuntu-devel-discuss mailing list