[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