On Monday 18 January 2010 21:08:33 Niels Breet wrote:
> I've been discussing this issue with some people before as hypothetical
> case, but now it seems that we run into it: Compiling an application
> against the PR1.1 SDK creates packages which can not be installed on
> earlier firmware releases.
The problem isn't really new: we have had it with all Maemo releases in the
past. For versions 1-3 it was something the developer had to handle
themselves, for version 4 it impinged on the autobuilder and is one reason we
insisted on a new name ("Diablo") for the release after Chinook, so it was
easy to build different versions (although, in fact, binaries built on
Chinook normally run perfectly well on Diablo).
For GPE I still build against Maemo 2, Maemo 3 and Maemo 4 and, in each case,
I use the SDK from the .0 release to build binaries which will run on any .*
release.
> The autobuilder uses the repository.maemo.org repository, so it
> automatically uses newer packages when they are available.
A particular autobuilder queue name should always use a fixed SDK release,
with contents which never change. That is what the "queue name" really
means, in my opinion.
> 1: Only compile against the original SDK.
> This prevents new features from ever be available to developers,
> but should work until there is real API/ABI breakage in a new
> firmware.
This should be the answer for "small" releases (like we have here). Just in
case anyone is confused, in most cases building against an old library does
**not** mean that running with a new version is prevented: so bug fixes in
newer releases of libraries work fine. The only thing this option prevents
is using a new **feature** (in particular, a new function call) in the new
library which was not in the old library.
> 2: Use version specific repositories
> This needs Application Manager support as we need to fetch from a
> separate repository every time. Also requires us to build against
> every sdk version known to man.
For "larger" releases (in particular, ones with new features in libraries
which developers may want to use), the release should be given a new name and
a new repository and a new autobuilder queue should be created. If backwards
compatability is expected, it would be feasible to populate the new
repositories (extras, extra-testing and extras-devel) by just copying the
packages from the previous release but new versions of the packages could be
built to use the updated libraries if they wished.
> 3: Depend on >= mp-fremantle-generic-pr | maemo-version
> We would need a hack in the autobuilder to add depends to pr and
> maemo version. This way a user needs to upgrade to at least the
> required firmware image. I think this will make it easier for an
> end-user to understand what is happening.
I don't like this. We should not have an application forcing a maemo software
upgrade. Different people will have very different tolerance to doing
software upgrades (most of us developers and power users are keen to try new
releases, but most ordinary users will resists as long as possible).
It certainly can't be the case that just building after the new release has
been shipped means your users have to upgrade. If I have thousands of users,
I need to be able to ship new releases to them without forcing an upgrade.
Don't forget that upgrades are not even available to all users at the same
time (today we have the Vodafone problem, which will only get worse in future
with different operator versions and different country versions available at
different times).
I do think there may be an option 1.5: create multiple autobuilder queues
which feed the same repository but build against different SDK releases. For
example, a "fremantle" queue which builds against the base release (for
ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for
ever), but both populate the same repository (extras-devel fremantle). That
would allow the applciation developer to decide which users they are willing
to support. If the application supports all fremantle users it submits to
the fremantle queue. But if it uses a new feature (or even an important bug
fix) from the pr1.1 release the maintainer could submit it to the
fremantle-pr1.1 queue.
If we did this, I wouldn't object to automatically adding a dependency on the
device software version, as long as it is worked out from which queue you
submit to.
Graham
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
