The SSU nightmare

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.

5 thoughts on “The SSU nightmare”

  1. Thanks for the update. It’s good to see this finally being discussed in the open, rather than third party developers discovering a buggy implementation of it during the beta releases.

    Can you clarify a few terms: “SO” == OS? And the “chicken-like” and “tiger-like” is just referring to the level of sophistication of the algorithms in HAM/apt respectively; or the aggressiveness or …?

    To be honest, I’d’ve thought the best option was to uninstall the third party package preventing the action the user’s requested (is this what apt would do?).

    The problem with disallowing explicit dependencies on packages that are currently part of the OS to prevent a future SSU breaking is that a future SSU could include new packages which are third-party provided currently (some random lib being an obvious candidate). So it’s not hard to find the edge cases here 🙁

  2. Andrew,

    Oops, yes, SO is OS in Spanish. Sorry about that. It’s already fixed.

    The chicken-like and tiger-like terms refer to the “smartness and boldness” for handling dependency problems. For example, APT could remove a problematic package, then install the other requested package and reinstall the previously removed package again. HAM is not that audacious.

    About you observation with the new package inclusion in SSU, according to the PM, that won’t happen. But I wouldn’t put my money on that.

  3. Hi Victor, sorry to be so late to the party… some clarifications for Andrew nevertheless. (Don’t know if he will ever see them, blogs are a weird communication medium that way…)

    The official technical term is “lion”, not “tiger”. “Turning the Application manager into a lion” means that it is using the most aggressive algorithm we can come up with to fulfill the users wishes: if all 3rd party applications needs to be removed to update your OS, then that is what it will do. It wont do it without getting conformation first, of course.

    We didn’t do this because it is a change with far reaching, uncertain consequences. The lion nature in itself is not problematic, but just changing the algorithms means we will need significant time to regain confidence. Weird things might happen with 3rd party packages. Also, significant UI interaction design would need to be done, helped by lots of experimenting and back and forth.

    I blame myself for not pushing harder for this. We could probably have done it for Fremantle. I was a chicken about this myself. :/

    Anyway, there is a red-pill setting “Use apt-get algorithms: that will turn the backend into a lion. The frontend will remain a chicken and not be able to stop the backend from doing real damage. So, feel free to experiment with this, but be careful. In all likelyhood, things will just work. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *