Task:SSU update repository procedure - Revision history

amigadave: links

amigadave — Mon, 19 Apr 2010 14:11:29 GMT

links

← Older revision		Revision as of 14:11, 19 April 2010
Line 1:		Line 1:
	{{task\|proposed}}		{{task\|proposed}}

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

	== What could have been ==		== 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 ==		== 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.		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.

twaelti at 18:32, 18 October 2009

twaelti — Sun, 18 Oct 2009 18:32:21 GMT

← Older revision		Revision as of 18:32, 18 October 2009
Line 34:		Line 34:

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

generalantilles: /* The Problem */

generalantilles — Thu, 25 Sep 2008 14:40:02 GMT

The Problem

← Older revision		Revision as of 14:40, 25 September 2008
Line 13:		Line 13:
	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.		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 ~~https~~://bugs.maemo.org/show_bug.cgi?id=3648 ~~[[User:fanoush\|fanoush~~]~~] 06:55, 25 September 2008 (UTC)~~	+	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 ==		== Proposed solutions ==

fanoush: /* The Problem */ 2nd problem - sources

fanoush — Thu, 25 Sep 2008 06:55:52 GMT

The Problem: 2nd problem - sources

← Older revision		Revision as of 06:55, 25 September 2008
Line 12:		Line 12:

	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.		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 https://bugs.maemo.org/show_bug.cgi?id=3648 [[User:fanoush\|fanoush]] 06:55, 25 September 2008 (UTC)

	== Proposed solutions ==		== Proposed solutions ==

generalantilles at 19:48, 24 September 2008

generalantilles — Wed, 24 Sep 2008 19:48:01 GMT

← Older revision		Revision as of 19:48, 24 September 2008
Line 1:		Line 1:
		+	{{task\|proposed}}
		+
	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.		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.

generalantilles: New page: 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 procedur...

generalantilles — Wed, 24 Sep 2008 19:47:27 GMT

New page: 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 procedur...

New page

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.

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