app manager: <package> breaks the 3rd party package policy

[mikkov]

Quim Gil reported that Mad Bomber is not installable from fremantle extras-devel.

Hi, I have tried to install Mad Bomber from Fremantle extras-devel but I get the error:

Mad Bomber breaks the 3rd party package policy

Unable to install


Because I've never heard of such error I decided to move discussion here.

Does anybody know what causes this?

Quim, is it possible to get more detailed error report from AM itself or by trying to install it with apt-get?

[Jaffa]

Never heard of it either. Deb info (on x86 at least) looks reasonable.

I haven't got time to grep through the h-a-m source (http://gitorious.org/hildon-application-manager) at the moment.

[Jaffa]

Have a look at src/apt-worker.cc lines 3085 and 3096:

http://gitorious.org/hildon-application-manager/mainline/blobs/master/src/apt-worker.cc#line3076

My guess is one of the depends conflicts with the SSU-installed packages (e.g. by requiring a higher version than installed on the device):

Depends: libc6 (>= 2.5.0-1), libsdl-image1.2 (>= 1.2.4-5), libsdl-mixer1.2, libsdl1.2 (>= 1.2.10-1), libx11-6, madbomber-data (= 0.2.5-3maemo4

[mikkov]

If that's the case then this cannot be fixed until SDK is updated. There could be other packages which require rebuilding too.

[lma]

Have a look at src/apt-worker.cc lines 3085 and 3096:

It's got to be the first one, since there are no conflicts in the package. This then results in the reported error message here (http://gitorious.org/hildon-application-manager/mainline/blobs/master/src/operations.cc#line128).


My guess is one of the depends conflicts with the SSU-installed packages (e.g. by requiring a higher version than installed on the device):

Depends: libc6 (>= 2.5.0-1), libsdl-image1.2 (>= 1.2.4-5), libsdl-mixer1.2, libsdl1.2 (>= 1.2.10-1), libx11-6, madbomber-data (= 0.2.5-3maemo4

All of the above (except madbomber-data) have equal or higher versions in the beta SDK already.

My C++-foo isn't great, but I suspect apt-pkg misuse or bug. This (http://gitorious.org/hildon-application-manager/mainline/blobs/master/src/apt-worker.cc#line3078) check should trigger for all the listed dependencies:


if (op == pkgCache::Dep::NoOp
|| op == pkgCache::Dep::GreaterEq
|| op == pkgCache::Dep::Greater)
continue;

or am I missing something?

[qgil]

Here you have, hope it helps.

/home/user # apt-get install madbomber
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
madbomber: Depends: madbomber-data (= 0.2.5-3maemo4) but it is not going to be installed
ukmp: Depends: python-pygame but it is not going to be installed
Depends: python-imaging but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
/home/user #

[qgil]

Coincidentally or not, there was an UKMP update. I have installed and now the story was different:

?
/home/user # apt-get install madbomber
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
madbomber-data
The following NEW packages will be installed:
madbomber madbomber-data
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 2485kB of archives.
After this operation, 3666kB of additional disk space will be used.
Do you want to continue [Y/n]?
WARNING: The following packages cannot be authenticated!
madbomber-data madbomber
Install these packages without verification [y/N]? y
Get:1 http://repository.maemo.org fremantle/free madbomber-data 0.2.5-3maemo4 [2459kB]
Get:2 http://repository.maemo.org fremantle/free madbomber 0.2.5-3maemo4 [25,6kB]
Fetched 2485kB in 4s (527kB/s)
Selecting previously deselected package madbomber-data.
(Reading database ... 27749 files and directories currently installed.)
Unpacking madbomber-data (from .../madbomber-data_0.2.5-3maemo4_all.deb) ...
Selecting previously deselected package madbomber.
Unpacking madbomber (from .../madbomber_0.2.5-3maemo4_armel.deb) ...
Setting up madbomber-data (0.2.5-3maemo4) ...
Setting up madbomber (0.2.5-3maemo4) ...
gtk-update-icon-cache: Cache file created successfully.
/home/user #

[qgil]

MadBomber works, apparently (just gave it a try, time to bed).

btw, you might want to consider using the interface with the accelerometers, but this is a topic for another thread. :)

[qgil]

So... is this 'third party package policy' about conflicting dependencies in extras? About third party packages that can't be authenticated? Both? Else?

[mikkov]

So... is this 'third party package policy' about conflicting dependencies in extras? About third party packages that can't be authenticated? Both? Else?

That you probably have to ask from Nokia :D

But to me it looked like that Application Manager wasn't able to resolve depencies, possibly because ukmp installation was somehow halfway.

[qgil]

You are right. Asked to Richard/Marius. The message appears, in theory, when installing a 3rd party app can mess a SSU. It's a young feature being tested these days, so let's not worry much about it now.

[mikkov]

I read the code again and I'm pretty sure that the reason was that madbomber has a depency to certain version of madbomber-data (madbomber-data (= 0.2.5-3maemo4)).

Depending to certain version of the base system would break SSU's, but depending to certain version of 3rd party package should be OK as long as it's comparable to madbomber-data (ie not a library).

I hope that the "the 3rd party package policy" is documented once it's done. It wouldn't hurt if it was discussed even before it was done.

[qole]

I hope that the "the 3rd party package policy" is documented once it's done. It wouldn't hurt if it was discussed even before it was done.

Yes, please. Perfect chance to avoid community backlash by discussing a policy that will affect the community before it is implemented.

[qgil]

Yes, the discussion is even in the plan and I guess it will come when there is a solid proposal in place. I have been told that this 'SSU check' has got its first implementation as a test a week ago...

[qgil]

Yes, the discussion is even in the plan and I guess it will come when there is a solid proposal in place.

Here we go: http://wiki.maemo.org/Extras/3rd_Party_Package_Policy

[mikkov]

Seems fine to me but following quote doesn't make sense to me (except that it's huge work).

How can we test that all 3rd party SW available doesn't break the SSU installation? Before SSU goes public to a repository, rebuilding all 3rd party SW is the best way. This is a huge work and can not be controlled easily, but at least it should be feasible within the maemo.org Extras scope.

I don't understand why all packages would need to be rebuilt when SSU is released.

[Jaffa]

I don't understand why all packages would need to be rebuilt when SSU is released.

Confused me at first as well. I guess it should actually be "any package which depends on a package in the new SSU must be checked for version compatibility". Maybe?

[Andre Klapper]

I tried to install gFTP in current Fremantle but that also was not possible as it "breaks the 3rd party package policy" according to the Application Manager.
However, running "apt-get install gftp-gtk" worked fine.
/me confused.

[qwerty12]

Looking at what has been said here, I guess it fails because:
gftp-common (= 2.0.18-17maemo4)

If it is failing because it's using = instead of >=; then it is rather stupid behaviour from the Application Manager.

[javispedro]

If it is failing because it's using = instead of >=; then it is rather stupid behaviour from the Application Manager.

And seems to contradict 3rd package policy as defined by qgil in wiki:

3rd party packages can not: (foo is the one of system update packages defines in SSU meta package)
Depends: foo ( = version A)

(neither gftp-common nor madbomber-data are system packages)

So I guess this is a h-a-m bug. Or I'm misunderstanding the policy.

[mikkov]

Most likely Application Manager isn't just finished yet.

[qgil]

Please file the bug. This is what early releases are for. Thanks!

[Andre Klapper]

Same issue when trying to install mediabox.

So did someone try using >= instead of = ?
qwerty12?

[HowHH]

Coincidentally or not, there was an UKMP update.:

There was a UKMP update? When? The maemo.org download page for it says it is at version 1.83 and was last updated 8/12/08. Is this in devel repository?

[Andre Klapper]

Filed https://bugs.maemo.org/show_bug.cgi?id=4754 about this.

[Andre Klapper]

So I now have a confirmation that the reason is that 3rd party applications are not allowed to have strict (=) dependencies on Nokia packages.
Time to contact the package maintainers it seems...

[qwerty12]

That would make sense if gftp-common and madbomber-data were packages made by Nokia.

I will not reupload gFTP with the change as the fault is not on my side.

[Jaffa]

That would make sense if gftp-common and madbomber-data were packages made by Nokia.

Indeed. I've raised this (http://lists.maemo.org/pipermail/maemo-developers/2009-July/019831.html) on maemo-developers as it's not clear what the policy is; where it's been discussed and why it was not raised by Nokia for discussion in the developer community before implementing it.

Not only am I annoyed and disappointed, I'm worried that it could well be implemented as a complete ban on "=", because a logical conclusion of the policy principles as described above would be that any explicit package version could conflict with a package brought in in a future SSU. Indeed, the only logical conclusion of "all SSUs must work all the time" is that all third party packages must be uninstalled before applying it! (And even that wouldn't guarantee it!)

[Matan]

So I now have a confirmation that the reason is that 3rd party applications are not allowed to have strict (=) dependencies on Nokia packages.
Time to contact the package maintainers it seems...

So kernel modules cannot be packaged by third parties?

[qgil]

it's not clear what the policy is; where it's been discussed and why it was not raised by Nokia for discussion in the developer community before implementing it.

The policy proposed is explained in the wiki page and is implemented in the beta code of the AM. I'm not sure either why it hasn't been discussed before bt the fact is that it's not carved in stone and nobody is claiming that is bug free.

I have left more comments in the bug (https://bugs.maemo.org/show_bug.cgi?id=4754#c1) report. Andre and the Igalia developer in charge of the implementation are in the Desktop Summit and I have chatted with both about this problem. Maybe not too much happens code during July since most of us will be on holidays but we will find a solution for this before Fremantle goes to the hands of users and this policy is effectively enforced by the AM.

[qgil]

Connecting people:

The SSU nightmare
http://blogs.igalia.com/vjaquez/2009/07/28/the-ssu-nightmare/

vjazquez is the developer in charge of implementing the 3rd Party Package Policy. Yesterday I put him in the CC of the bug.

[qgil]

And for those interested in this discussion but not following the bug, a fix (https://bugs.maemo.org/show_bug.cgi?id=4754#c6) has been committed to the Application Manager. The new version is in its way to be integrated in the Fremantle release.

So you see, there is time to draft a policy, publish some code, discuss, fix problems... before any package makes it even to extras-testing. No harm done.

[Jaffa]

So you see, there is time to draft a policy, publish some code, discuss, fix problems... before any package makes it even to extras-testing. No harm done.

Indeed, and the response to this issue has been fantastic. However, I hope you recognise that although there was time to go through this workflow; it'd've been better to avoid the issue altogether; by having design discussions for open components in the appropriate place. In this case, H-A-M's mailing list: maemo-developers.

This is especially important given that h-a-m is one of the few Nokia-owned and user-visible components which actually has volunteers submitting patches which end up getting shipped (such as myself and qwerty12).

So there was "harm done" to the perception that Nokia was increasingly getting "being open" right.

[qgil]

Yes, agreed. We are having more open source code released sooner and more often, but we haven't got into more solid open development, except in those components purely developed upstream.

To be honest, I didn't even know about this policy before it was implemented. I also believe the reason was that, as it was conceived, it was not even meant to affect anybody else than Nokia alone with the official releases.

Anyway, bug fixed (https://bugs.maemo.org/show_bug.cgi?id=4754) and released. MadBomber installs and plays just fine in Maemo 5 now.