dependency resolution doesn’t use its own decisions

[Bogdan Butnaru]

Binary package hint: aptitude

Hello! I recently encountered a problem I noticed earlier and decided to report it. Consider the snippet I pasted below. It’s a run of aptitude when I asked it to install the current version of Amarok (2.something), for testing. I had used until now a forked version of Amarok 1.4 from my own PPA. The exact packages are not particularly important, I’ve encountered the same behavior from aptitude, and worse, on other occasions. It’s the structure of the dependencies that’s important.

In this case, there are packages amarok14 and amarok14-common, which depend on one another, and also amarok14-engine-xine. The later recommends amarok14 (since it’s not useful without it, but the exact reason is not important). amarok14 conflicts with amarok (the 2.x version), because it uses the same paths; this avoids the two versions messing each-other’s databases.

So, what happens is that aptitude correctly notices the conflicts, and offers to remove amarok14, amarok14-common and amarok14-engine-xine; so far so good. However, it also mentions at the end “Leave the following dependencies unresolved: amarok14-engine-xine recommends amarok14”. This is incorrect: the action it proposed above would uninstall a...-engine-xine, so the “recommends” dependency would no longer be present after the removal (thus, it wouldn’t be left unresolved).

At the very least, this behavior is confusing. However, I’m pretty sure I encountered similar behavior in the past, when the dependencies “left unresolved” after the removal were stronger and/or more complex, and aptitude seemed to be confused by them. On occasion it didn’t notice simple resolutions for some package conflicts, apparently because of this kind of issue. I’m pretty sure that its “cost” estimates for some resolutions are off quite a bit.

Since aptitude’s behavior for complex updates (e.g., a distribution upgrade) is quite arcane in cases, I’d be surprised if this bug didn’t cause quite a few ugly messes. It should be fixed.

***********************
bogdanb@mabelode:~$ sudo aptitude install amarok
The following NEW packages will be installed:
  amarok amarok-common{a} amarok-utils{a} kdemultimedia-kio-plugins{a} libindicate-qt0{a} libkcddb4{a}
  libknewstuff2-4{a} libloudmouth1-0{a} libqtscript4-core{a} libqtscript4-gui{a} libqtscript4-network{a}
  libqtscript4-sql{a} libqtscript4-uitools{a} libqtscript4-xml{a} libtag-extras1{a}
0 packages upgraded, 15 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.0MB/13.2MB of archives. After unpacking 51.0MB will be used.
The following packages have unmet dependencies:
  amarok14-common: Conflicts: amarok (>= 2:2) but 2:2.3.1-1ubuntu5 is to be installed.
                   Conflicts: amarok-common but 2:2.3.1-1ubuntu5 is to be installed.
  amarok14: Conflicts: amarok but 2:2.3.1-1ubuntu5 is to be installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1) amarok14
2) amarok14-common
3) amarok14-engine-xine

     Leave the following dependencies unresolved:
4) amarok14-engine-xine recommends amarok14 (= 2:1.4.10-0ubuntu3~ppa5)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: aptitude 0.6.3-2ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-17.23-generic 2.6.35.2
Uname: Linux 2.6.35-17-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Thu Aug 26 18:55:49 2010
EcryptfsInUse: Yes
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: aptitude

[Rolf Leggewie (r0lf)]

Thank you for the thorough analysis with which I agree in principle. Do you have a more recent test case?