[Desktop_architects] What's an ISV to do when a distro upgrade disables the ISV's repo?

Matthew Tippett tippettm at gmail.com
Tue May 5 12:50:46 PDT 2009


Using "5 Why" to push up the problem chain to understand the root cause

Why does the the distro disable 3rd party repositories...  Some answers 
could include

1) Effectively increase the absolute priority of the distribution 
packages to allow the update.  If the third party app is force to be 
removed to satisfy a dependency, so be it.
2) Remove the possible sources of conflicting/unstable/incorrect 3rd 
party libraries that may have a higher version match than the distributions.

(Any other thoughts?)

Now, obviously you are considering the "damn, it happened, what do we do?".

To initially get to that point, the user has taken direct action to 
enable the updates.  Based on that, b) or c) would appear on the surface 
to be the better two.  You seem to be assuming elevated access for c), 
so b) seems to be the best option - using xdg-su or similar to inform 
the user, elevate their access, and enable the 3rd party repo.

Do you have any use cases driving the user's experience in your case?

Regards,

Matthew

-------- Original Message  --------
Subject: [Desktop_architects] What's an ISV to do when a distro upgrade 
disables the ISV's repo?
From: Dan Kegel <dank at kegel.com>
To: Desktop_architects at lists.linux-foundation.org
Date: 09-05-05 03:36 PM

> So, upgrading from one version of ubuntu to another
> happens to disable all non-distro repositories.
> Which plays hob with autoupdate for apps that came
> from ISV repositories.
> 
> What's an ISV to do?
> 
> a) nothing; just grin and say "we're ok with being unable to deliver
> security updates"
> b) on next run of the app, prompt the user, e.g.
>    "Something turned off autoupdates for this app.  OK to re-enable updates?"
> c) silently re-enable the repo
> 
> I don't like any of the above choices.  Which is the lesser evil?
> - Dan



More information about the Desktop_architects mailing list