Editing Task:SSU update repository procedure

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

Nokia's new procedure with the Tableteer update repository for 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.

== 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.

== 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 ([[Seamless Software Update#osso-software-version|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 [http://bugs.maemo.org/show_bug.cgi?id=3648 bug #3648].

== Proposed solutions ==

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

=== 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.

=== 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.

=== 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.
[[Category:Tasks]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Templates used on this page:

Template:Ambox (view source) (semi-protected)
Template:Task (view source) (semi-protected)

Retrieved from "https://wiki.maemo.org/Task:SSU_update_repository_procedure"

Personal tools

Navigation

Views

Editing Task:SSU update repository procedure

@@ Line 1: / Line 1: @@
 {{task|proposed}}
-Nokia's new procedure with the Tableteer update repository for [[Seamless Software Update|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.
+Nokia's new procedure with the Tableteer update repository for 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.
 == 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.
+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.
 == 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 ([[Seamless Software Update#osso-software-version|osso-software-version-rx*4]], for example), one of the biggest side-benefits of the SSU system is eliminated.
+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 ([[Seamless Software Update#osso-software-version|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.