With the change to the new server infrastructure, we also changed the way developers can use dput to upload their source packages to the autobuilder. We created a special host named drop.maemo.org for uploads using dput (and scp). The uploading to Extras wiki page has been updated with the correct information. Short story: replace garage.maemo.org with drop.maemo.org and continue like before.
Another change we had to make was how packages are promoted from diablo Extras-devel to Extras. The old promoter was no longer suitable for the current setup and needed to go. Promotion now works the same way as it works for fremantle Extras-devel to Extras-testing (direct promotion). The package interface for diablo Extras-devel can be found here.
There are still a few features missing for the diablo part of the packages interface, but promotion should work. I'll add build logs and context sensitive searches at a later point.
Friday, January 29, 2010
Monday, January 18, 2010
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 and 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.
Discussions on the maemo-developers list or talk.
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.
Discussions on the maemo-developers list or talk.
Subscribe to:
Posts (Atom)