Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: mobile-software-updates

• Packages affected: update-manager, update-notifier

Summary

The mobile plattform needs a application to do software updates with.

Release Note

TBD

Rationale

The mobile plattform will have to apply software updates just like a regular desktop system (because its so close of being a regular desktop system). The application we use for this on the desktop is update-manager and it should be ported to the mobile plattform.

Use Cases

1. libfoo has a security issue that might make the mobile device vulerable. A update should be easy to apply

Caveat

This spec will discuss how to apply software updates on the mobile plattform. The problem of how to enable easy install of additional software is not discussed. This should go into a seperate spec.

Design

Update-manager currently performs two functions. One if regular updates of packages for (security) updates. The second is to do a full release-upgrade if a new version of ubuntu is released. Both needs to be adjusted for mobile. There is also the update-notifier that perform the apt-get update and notifying the user.

UpdateManager

The following changes were discussed:

1. Instead of showing all binary package updates, show a application list
2. Provide a feature to show marketing information intead of changelogs
3. Should be possilbe to show changelogs in html (should be easy to edit for the marketing people)
4. Show update information translated
5. There will be no unattended-updates (the unattended-upgrades package is not needed on the plattform)
6. Do not run if battery is low (warn if on battery instead of on power)
7. Make sure that it is possible to push new apps (like a chat client)

8. The meta-release uri (currently http://changelogs.ubuntu.com/meta-release) needs to be easily changeable for the mobile team/customer so that release-upgrades can be done independently of the regular release schedule

ReleaseUpgrader

In place upgrades are dangerous (because something may break during the upgrade). We will still support them, there is always the option to flash the new image if the upgrade went wrong.

To get a smooth experience the upgrader will ensure that that a) full release upgrade can only be performed while on power (not on battery) b) forces the user to backup his data (plus sources.list and installed appliations). If there are 3rd party package installed the upgrade should not be performed (maybe having a red-pill mode and/or a very strong warning).

The automatic upgrade testing should be extended for mobile. It is strong advised that each upgrade is tested with the automatic tools beforehand.

update-notifier

The update-notifier application is responsible for displaying the notification in the notification area about possible updates. It also installs the configfile that makes apt run its nightly apt-get update cron job. The only change requested here is that the notifications show "you have updates" instead of the amount of updates (as it is currently doing on the regular desktop).

gdebi

This is the application that makes it easy to install deb packages directly. It should never be enabled unless the user goes into some sort of red-pill mode because its too dangerous to install debs unrestricted.

Implementation

UpdateManager

The points in the design section are adressed one by one:

1. AppView: based on source-packages and the app-install-data information (Sebastian Heinlein has some code for this in his "appview" branch). Test if the app-install-data information is not too big and too much of a performance problem. If so, either optimize or build a smaller app-install-data package for mobile (without universe?)

2. Set a different changelog URI schema (marketing.ubuntu.com instead of changelogs.ubuntu.com), the mobile team (or customer) is responsible for setting up the required web location.

3. A additional changelog view is added that is based on GtkHtml. The customer needs to ensure that the html provided renders correctly in it (its not a full gecko).

4. a ".$lang" code is appended to the http uri when a update info uri is requested. If that gives a 404 it falls back to untranslated.
5. remove "unattended-upgrades" dependency and make it a recommends
6. integrate with gnome-power-manager (or the hildon/moble equivalent) to get information about battery/power status
7. This can be done via normal additions to the Recommends/Depends of mobile-desktop (or the equivalent meta-package for the plattform). No code changes required.
8. Instead of hard-coding the meta-release file we need to add a config option (gconf?) for this

ReleaseUpgrader

A new DistUpgradeViewHildon will be developed to integrate well with the hildon desktop. The controller is expanded so that its easy to plug additional policies. Those policy can then be used to ensure that a full backup is run before the upgrade or that we only upgrade when on ac-power.

update-notifier

• Check how much changes are required to build the update-notifier on hildon
• Check if libnotify can be used for the notificaton bubbles and if not,
  • what other options are available.

UI Changes

The current gtk/glade code needs to be changed so that it integrates well with hildon.

Test/Demo Plan

TBD

Outstanding Issues

Is there a good "howto port your glade app to hildon" document?

BoF agenda and discussion

During the session the problem of installing additional software was discussed as well. On the regular desktop we use "gnome-app-install" for this. It may be too resource intensive for a mobile device (this needs to be checked). The alternative is a web based installation system based on apturl (possible restircted to certain websites only). In the future we may want to provide "apps-for-pay", but this is out of scope for this spec too (a similar mechanism as for private PPAs may be used).

The problem of 3rd party packages was discussed but there was no conclusion other than that it would be good to have a sandbox mode and that they are a big QA problem. Maybe we need a red-pill mode for this.

CategorySpec