• Intro
• Downloads
• Community
• Development
• News
• TALK

Task:SSU update repository procedure

Latest revision as of 14:11, 19 April 2010

This task is in the list of maemo.org development proposals, please help planning and getting it ready for a sprint. Put a note on the talk page if you're interested in helping work on this task. Please see the talk page for discussion.

Nokia's new procedure with the Tableteer update repository for Seamless Software Updates (SSU) updates leaves much to be desired, and this article will outline some of the problems and pitfalls of the chosen procedure, as well as some possible solutions to these problems.

[edit] What could have been

The new SSU system was something of a coup for the community when it was first announced. Not only were flashing updates a thing of the past, but it meant Nokia might decouple minor updates from major OS releases, which would mean more frequent, smaller bug fix updates to individual packages allowing bug fixes to come sooner and more often. It also meant that system packages would be available from a repository, so when something went wrong while playing with them (say, while testing out the latest MicroB SVN), one could simply grab a fresh copy from apt, instead of having to reflash or pull the package from another device.

[edit] The Problem

Unfortunately, with Diablo and SSU, Nokia has, for whatever reason, decided that each individual SSU release needs its own update repository (i.e., diablo/ for 23-14 and diablo-1/ for 30-2), and since Nokia has decided not to populate the latest repository with even the most basic of packages (osso-software-version-rx*4, for example), one of the biggest side-benefits of the SSU system is eliminated.

It's easy to remove o-s-v, difficult to reinstall it without it being available in the update repository, and quite possible to end up with reboot loops if you attempt an upgrade without it.

There is also secondary problem that goes with updates. The problem of updating SDK repository with relevant sources for binaries released in the update. Having no sources is against spirit (and word) of GPL and it also causes practical problems for developers and indirectly also for regular users. See also bug #3648.

[edit] Proposed solutions

Fortunately, the solutions to this problem are very straightforward and easy to implement.

[edit] Most desirable

All updates are pushed through a single repository per distribution (diablo/ for Diablo, fremantle/ for Fremantle, etc) and all of the system packages (i.e., everything o-s-v depends on) are available in that repository.

This means all system packages are installable from through apt, o-s-v is always available, and the world is generally a happier place.

The downside, of course, is the question of updates. Will you be able to jump from a 23-14 to a 41-5 without going through each individual update in between without issue (my bet is yes)? I don't know enough about Linux packaging to guarantee that that would be safe nor, will Nokia be likely to want to do the testing to ensure that it is. So this may not be an acceptable option, though it did seem to work OK during the Diablo beta period.

[edit] Compromise

Each update has its own repository (diablo/, diablo-1/, diablo-2/, etc), but all of the latest packages for that update are available there, so they can be easily reinstalled if need be. This is a good compromise choice, as it doesn't offer too many update-system stabilities issues for Nokia to worry over and doesn't leave users high-and-dry for packages.

[edit] Bare minimum

At the barest minimum, o-s-v needs to be available from each update repository as soon as it's live, as it's very easy to remove it doing a variety of harmless things, but very difficult to re-install it if it's not available (as the nokia-repositories package will nuke your old update repo in the process of the upgrade), and an attempted apt-get upgrade without o-s-v installed can lead to reboot loops.