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

Paulo Trezentos Paulo.Trezentos at caixamagica.pt
Wed May 6 02:29:59 PDT 2009


Hi.

Dan Kegel escreveu:
> 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?
>   
It depends a lot of the original model in which the application was 
deployed in the system:

   1) Was it included in the official distro repositories and installed 
with the system?
        Example: applications which license allows distros to include it
        after permission be given: acrobat reader, skype, drivers, ...
 
   2) Was it installed from ISV repos but using the system package 
platform (RPM / DEB)?
        Example: don't know if it is active, but there was this Google repo:
            deb http://dl.google.com/linux/deb/

   3) Was it installed directly in the file system without being in a 
system package?
        Example: ./configure - make - make install apps, ...

The way to go for ISVs relating the updates is of course depending on 
the strategy above.

In the first case, Linux distro editors are the channel to updates.

In the second case, which I think was the one you mentioned, the policy 
of system update applications should be different between "official 
distro repos" and "ISV repos".
The GUI auto-update app (a layer above apt / yum) may ask the user 
something like:
    "I will update automatically from official repos but you have the 
following sources active:
                 |   |  ftp.isv1.com ....
                 |   |  ftp.isv2.org ....
                     Mark the ones you want to be active during the update"
With a   "- Don't ask me more" option.

In complete unattended updates, I don't think that removal operations 
should be performed at all by the meta-installed (apt, yum, yast). Not 
only that may result in removing third-party applications but also 
critical system components.

Some of our experience in this field.
In Caixa Mágica, a portuguese Linux distro since 2000, we have some 
large deploys of Linux CM machines (500.000 classmate notebooks, 110.000 
PCs from HP in class rooms with dual boot and 40.000 notebooks only with 
Linux for Portugal Telecom customers). In those deploys, all the 
software included is at distro repos and if ISVs  want to include 
software are encouraged to work with us in package their applications 
and made it available in our repos.
Although we use Mandriva packages as a base, we have our own 
meta-installer (a version of Apt-RPM with rollback, DUDF reports,  PBO 
dependency solvers,...) and GUI update application (cm-software-updater).
For our mass-market customers (the long tail of OS) we encouraged 
strategically ISVs to have their own repos.

Cheers.
> 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
> _______________________________________________
> Desktop_architects mailing list
> Desktop_architects at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
>
>   


-- 
 _____________________________________
| Caixa Mágica 
|             - Energia Open Source
| http://www.caixamagica.pt         




More information about the Desktop_architects mailing list