[maemo-developers] Maemo 5 PR1.2 and Extras

[From: Marius Vollmer]

ext Dave Neary <dneary at maemo.org> writes:

> Then a new version of the SDK comes out, which is not backwards
> compatible. A number of potentially bad things can happen:

I agree with your points in general, but I want to qualify them a bit.

There are two issues:

- I think it is very important to be able to release new OS versions and
  new SDK versions that add APIs.

- I also think that it is important to be able to remove APIs in a
  controlled way, but much less so than being able to add APIs, and we
  can leave that for later, once we have figured out how to add APIs.

> 1. New uploads get compiled with the new SDK, and get downloaded onto
>    phones with the old OS, where they don't work.

This is one kind of bug: the new SDK has added APIs compared to the old
API, and applications that use the new SDK wont run on OS versions that
doesn't have that API.

Some will not work, and some will not even install, but most of them
should install and work.  New uploads should only not install or work
(by necessity) when they actually use the added API.  If they don't use
any of the added API, they should install and work with the old versions
of the OS.

Our SDKs are not very good at producing the necessary dependency
information for this (i.e., our library packages don't use
dpkg-gensymbols, and we do not maintain the -V option of dh_makeshlibs),
and as a result, almost all packages will erroneously refuse to install
into a old OS when they have been compiled in a new SDK.

This is a bug in the SDK (i.e., in the tools and in the packages), it is
unfortunately _not_ trivial to fix, but it is very worthwhile to fix it.
(RPM does it differently, so maybe this isn't actually worthwhile to
fix, but let's ignore that for now...)

We should at least check each new SDK release for undesired changes in
the shlibs files.

> 2. Developers working with the old SDK upload applications which don't
>    even build with the new SDK

This is a different kind of bug: this will happen when the new SDK has
removed APIs compared to the old SDK.

It's a bug in the SDK and should be fixed.

> 3. To mitigate 2, we decide that all Extras apps need to be recompiled
>    with the new SDK, [...]

That would be foolish, and we should not do it.  As you say, we would
run into the SDK bug responsible for category 1 above.  We can and
should avoid that by not recompiling applications just because the SDK
has been updated.

Instead, before accepting a SDK release, we should check whether it can
still compile all the Extras apps.  If not, we have found a bug, either
in the SDK or in the Extras app.  That bugs needs to be fixed, and there
wont be many of these.

> All of these push inconvenience to the phone user & application
> developer - all unnecessary overhead, especially if the APIs haven't
> changed and there are issues with run-time library versions (as we saw
> with PR 1.0 to 1.1).

Agreed.

> The only way to avoid badness when upgrading the SDK in a
> not-backwards-compatible way is to have scratchbox, every developer
> copy of the SDK, and the N900 firmware all upgrade at the same time.

That's fortunately not the only way, although the way outlines above
isn't particularily easy.  The established GNU/Linux upstreams and
distributions have this pretty much under control.