In the Maemo domain, there’s a concept called SSU, Seamless Software Updates, which is the mean to update the whole operative system without reflashing the device.
This concept is relatively new in the mobile device domain, where reflashing has been the common upgrade path. But this idea is as old as GNU/Linux distributions.
Maemo uses the Debian format packages and dpkg /APT for their handling.
Meanwhile in Debian we are used to the dist-upgrade command in APT to upgrade to the new OS release, in Maemo is not the case because each OS release has a specific hardware target, so there is no need to handle complex dependency handling.
And that is the historical reason that the Hildon Application Manager does not use the APT algorithms for dependency handling. Instead of that, it use custom chicken-like algorithms: if the dependencies are not fulfilled without any foreseen problem, the package installation, upgrade or removal is rejected.
The Maemo OS upgrades are done through a meta-packages, which is merely a list of package dependencies to conform the new release. And this is all the magic in the famous SSU.
But this approach posses a couple drawbacks, which, in Fremantle, had grown disproportionally given the dimensions of the project.
First, the number of packages which conform a new release is so big, that the package section in the list file is bigger than the buffer size allocated by APT to parse it. We already filed a bug in Debian about this matter. It seems the problem is an integer overflow.
Second. It is quite easy to break the SSU process: if you install a third party application with a hard dependency to an OS package, the meta-package of the next release will fail, given the chicken-like nature of H-A-M when solving dependencies problems.
The adopted solution is impose a dependency policy for third party packages, which current implementation had triggered a community discussion.
The other proposed solution, use the tiger-like algorithms available in APT, was discarded given the risk of the needed changes in the apt-worker versus the available time frame.
No, there is not conclusion yet about the third party policy issue.