[maemo-developers] PR1.2 SDK for Extras-devel: how to solve?

From: Andrew Flegg andrew at bleb.org
Date: Wed Apr 7 16:55:51 EEST 2010

The number of issues being caused by the deployment of PR1.2 SDK to
the fremantle autobuilder is becoming critical. It doesn't even matter
when PR1.2 is released, as we should have a way of dealing with this
in-place for the next upgrade.

After the PR1.2 SDK was released, Niels deployed it to the
autobuilder; enacting a plan which was discussed on this list. This
has caused problems with libhildon dependencies, but the problems
aren't just limited to that library:


Both Niels and the Council believe we should do something to assist.

We *need* to do something, both to improve the situation in -devel and
-testing today, and test an approach for the next upgrade.

The main requirements here are, I think:

 * It's not an excessive amount of work
 * It's a viable long term strategy
 * The QA process doesn't get broken

Thoughts and comments from developers, or anyone else with a idea,
will be much appreciated.

1) Deploy SDKs as they are released; treat -devel and -testing as trunk.

This is what we have now, I think we can say it doesn't work if
there's going to be more than a few days between SDK release and
device upgrade. Since Nokia doesn't pre-announce release dates, and
last minute bugs could cause problems; I think we can rule this one

2) Revert the builder.

This is basically a step backwards. "Changing the builder config is
easy. Cleaning up -devel and rebuilding the affected packages is quite
some work as we don't have any scripts for that made yet."

3) Hack the SDK, create some kind of hybrid.

This'd be bad enough if limited to just libhildon, but isn't viable
and WILL cause unforeseen problems. Veto :-)

4) Create separate repos, build queues for pre- and post-1.2.

Similar to what's been done for Extras proper. "Creating the repos
will be about a day work, but the part that sits on top of that
(management scripts, Packages interface, QA queue) will probably take
a week of work."

There are hard issues around QA here.

5) Try building in each SDK in turn.

My suggestion; when someone uploads to "fremantle" auto-builder it
attempts to build the package against the PR1.1 SDK. If it succeeds,
it goes into Extras-devel. If it fails to build, it gets built with
the PR1.2 SDK, and so on.

For an app with compile time symbol resolution (e.g. C/C++), this'd
handle both cases quite nicely. Python apps would have to depend on
the specific versions of bindings which gave them the features they
wanted - again, not too much of a problem.

At extras(-stable) promotion time you could even decide, based on
actual binary package dependencies, whether to put in fremantle-1.2 or
both fremantle-1.2 & fremantle extras repos. This would fix another
common complain, "what if I don't upgrade for a few weeks".

Larger packages could be prevent from being tried to built twice by
stating a forced build dependency on a PR1.2 version of any system

Some software won't install from -devel and -testing as it does now,
but that will be reduced to the set of software which is actually
using features that are unavailable. A HAM patch could grey out
applications which were uninstallable, or show some other indication.

This is, effectively, reinventing the more intelligent dpkg-shlibdeps:


However, it deals with the following three circumstances:

 1) Application uses API which has changed in later SDK. This
    will be built with PR1.1 SDK, succeeds and goes into
    Extras-devel. Can be promoted to Extras-testing but
    there's no clear way for a tester to know it won't work
    if their device is running the latest OS.

 2) Application uses API which is unchanged in later SDK.
    This will be built with PR1.1 SDK, succeeds and goes into
    Extras-devel. Can be promoted to Extras-testing and
    tested on any device with PR1.1 or PR1.2. Once promoted
    it COULD go into fremantle and fremantle-1.2.

 3) Application uses API which is introduced in later SDK.
    This will be built with PR1.1 SDK and fail. It will
    be rebuilt with PR1.2 SDK, succeed and go into
    Extras-devel. Can be promoted to Extras-testing and
    tested by testers using the most recent release.
    Once promoted it will go into fremantle-1.2.

6) Case-by-case basis.

Developer complains: add a temporary exception to autobuilder to build
$APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as

Thanks in advance,


Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
Maemo Community Council chair
More information about the maemo-developers mailing list