[maemo-developers] Backwards compatibility broken PR1.1 SDK

[From: Marius Vollmer]

ext Graham Cobb <g+770 at cobb.uk.net> writes:

> It is still my view that, if at all possible, applications should install on 
> the initial release.

Yes, this is very important.

[ Still, it is also important to give good guidance to the user when it
  does have in fact to update the OS before he can install a certain
  application.  But let's concentrate on your point here.
]

You propose to achieve this by building (most) applications in the SDK
that has been released with the initial release.

This means that the build environment for (the majority of) applications
will not be updated and we have no good way to fix bugs in it.  This is
a very high price to pay, IMO.

The build environment will not be updated since the SDK releases done by
Nokia are not able to produce applications that can be installed on
older OS releases.

And this is the real problem that we should attack: We (Nokia) needs to
make SDK releases that produce applications that can be installed on
older OS releases, unless they really do in fact need features that are
only available in a newer OS release.


This is the next step in Maemo's path to distribution enlightenment.
Maybe it comes a bit late, but better late than never.


The primary mechanism at work is Debian's 'shlibdeps' machinery.  This
machinery determines how the dependencies look that applications acquire
at build time.  We (Nokia) need to master this machinery much better
than we do now.

     man dpkg-shlibdeps
     man dh_makeshlibs
     man dh_shlibdeps

First, we can analyze the package.shlibs files in a SDK release to see
building against which packages will require newer OS releases than the
previous SDK release.  If we are not happy with what we find, we can
reject that SDK release.  (Of course, this analysis should be done
continously and not only once we have a release.)

Second, we need to seriously work towards producing 'better'
package.shlibs files, and to start using package.symbols files.

Ideally, there shouldn't be any 'accidental' dependencies: If a
executable in package-A links against a library in package-b, then
package-a should depend on "package-b (>= VER)" where VER is the lowest
version of package-b that has all the symbols that package-a actually
uses.

This can be achieved with package.symbols files.

    man dpkg-gensymbols

A compromise to using dpkg-gensymbols is to manually pass a good value
to the -V option of dh_makeshlibs.  This is the least we should aim for.

> All we need is an exception process for the very, very few apps which
> want to make use of the few new features introduced in the new
> releases.  That is why I proposed the alternate builder queues which
> will cause the builder to use a later SDK.  Any application built
> using one of the alternate queues will not install on all versions of
> Fremantle so using it is discouraged unless it is necessary.

This will work, but it would be a testament to our (Nokias) incompetence
of making good SDK releases.  I hope we can avoid that.  But it is
certainly an option, if only temporarily.