Backwards compatibility broken PR1.1 SDK
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. In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem. The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available. For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented. How can we work around this problem: 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. 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. 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. We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description. Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time. If you have an alternative solution on how to go about fixing this issue, then please let me know. Can we, like with the opt problem, come to a solution with community power[tm]? |
Re: Backwards compatibility broken PR1.1 SDK
Meta-question (whilst we have a further brainstorm on IRC): Would this be better in the "Development" forum? Do we expect the solution to come from the "Community" or the community of developers?
ObShlibs: javispedro found http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps - which'd be perfect, if we had the right versions of dpkg-shlibdeps and .symbols files :-/ |
Re: Backwards compatibility broken PR1.1 SDK
Also, on both the mailing list and IRC it has been suggested a system where the uploader chooses the "minimal firmware version required" (i.e. via flag in package control file) before uploading a package and then it goes to a specific firmware autobuilder & repo. Let's call that "Option 4"?
Cons: requires H-A-M modifications, requires users that want to use newer firmware features to appropriately select the minimal firmware. IMHO, using the enhaced shlibdeps + option 3 would be cleanest. You get the autobuilder to "know" which firmware version is really the minimal one required, and thus the autobuilder can generate packages with the minimal required >= mp-fremantle-generic-pr dependency (or maybe H-A-M gains the required intelligence to do that, even if it means "checking with a server"). I expect most packages (think Debian ports) not to need the latest&greatest, so this does not kill non-latest firmware users as much as option 3 alone. Of course, this seems to be the most difficult, since it requires many changes to all system library packages. |
Re: Backwards compatibility broken PR1.1 SDK
I don't see where the problem is. Say my package needs PR1.1, why would it? Because of a certain version of a package, let's say libtelepathy-glib0 >= 0.7.37. Then all you need to know is find out which SDK provides that minimal version of the package.
|
All times are GMT. The time now is 05:17. |
vBulletin® Version 3.8.8