Package: aptitude
Version: 0.6.3-3.2
Hi,
I'm running into an issue with the aptitude interactive resolver where its
first response to "aptitude install dnsutils", when an upgrade is
available, involves removing dnsutils, and only the second option proposes
to upgrade it and other packages needed in order to make the upgrade
happen.
The setup is that Ubuntu Maverick released with bind9 1:9.7.1.dfsg.P2-2,
and now has the security update 1:9.7.1.dfsg.P2-2ubuntu0.1 (in
maverick-security and maverick-updates). The bind9 source package has a
bunch of binary packages: relevant to this issue are bind9-host, providing
the 'host' command, and dnsutils, providing the 'dig' and 'nslookup'
commands, as well as a number of libraries that both bind9-host and
dnsutils depend on. These are versioned dependencies, so effectively
bind9-host and dnsutils need to be at the same version, as do their
libraries.
If I take a system with the release (-2) version installed, run "aptitude
update", and then run "aptitude install dnsutils", I would expect it to
upgrade to the -2ubuntu0.1 version, or at best leave dnsutils alone.
Unfortunately, that's not what the resolver does. To make sure the Ubuntu
patches aren't relevant, the following transcript comes from a Squeeze
sbuild chroot, where I'm temporarily clobbering sources.list with
Maverick's repositories to demonstrate the issue:
####################################################################
builder@zulu:~$ schroot -c squeeze-i386-sbuild -u root
zulu:/home/builder# apt-get update
[...]
zulu:/home/builder# apt-get install aptitude
[...]
zulu:/home/builder# apt-cache policy aptitude
aptitude:
Installed: 0.6.3-3.2
Candidate: 0.6.3-3.2
Version table:
*** 0.6.3-3.2 0
500 http://debian.lcs.mit.edu/debian/ squeeze/main i386 Packages
100 /var/lib/dpkg/status
zulu:/home/builder# apt-key add ubuntu-ftpmaster
OK
zulu:/home/builder# cat > /etc/apt/sources.list
deb http://mirrors.mit.edu/ubuntu maverick main universe
zulu:/home/builder# aptitude update
[...]
Current status: 66 updates [+66], 31282 new [+31282].
zulu:/home/builder# aptitude install dnsutils
The following NEW packages will be installed:
bind9-host{a} dnsutils geoip-database{a} libbind9-60{a} libcap2{a}
libdns66{a} libgeoip1{a} libgssapi-krb5-2{a}
libisc60{a} libisccc60{a} libisccfg60{a} libk5crypto3{a} libkeyutils1{a}
libkrb5-3{a} libkrb5support0{a}
liblwres60{a} libxml2{a} sgml-base{a} xml-core{a}
0 packages upgraded, 19 newly installed, 0 to remove and 66 not upgraded.
Need to get 5511kB of archives. After unpacking 12.7MB will be used.
Do you want to continue? [Y/n/?] y
[...]
zulu:/home/builder# cat >> /etc/apt/sources.list
deb http://mirrors.mit.edu/ubuntu maverick-updates main universe
zulu:/home/builder# aptitude update
[...]
Current status: 80 updates [+14], 31329 new [+47].
zulu:/home/builder# aptitude install dnsutils
The following packages will be upgraded:
dnsutils libbind9-60 libdns66 libisc60 libisccfg60 liblwres60
6 packages upgraded, 0 newly installed, 0 to remove and 74 not upgraded.
Need to get 1095kB of archives. After unpacking 0B will be used.
The following packages have unmet dependencies:
bind9-host: Depends: libbind9-60 (= 1:9.7.1.dfsg.P2-2) but
1:9.7.1.dfsg.P2-2ubuntu0.1 is to be installed.
Depends: libdns66 (= 1:9.7.1.dfsg.P2-2) but
1:9.7.1.dfsg.P2-2ubuntu0.1 is to be installed.
Depends: libisc60 (= 1:9.7.1.dfsg.P2-2) but
1:9.7.1.dfsg.P2-2ubuntu0.1 is to be installed.
Depends: libisccfg60 (= 1:9.7.1.dfsg.P2-2) but
1:9.7.1.dfsg.P2-2ubuntu0.1 is to be installed.
Depends: liblwres60 (= 1:9.7.1.dfsg.P2-2) but
1:9.7.1.dfsg.P2-2ubuntu0.1 is to be installed.
Internal error: found 2 (choice -> promotion) mappings for a single choice.
The following actions will resolve these dependencies:
Remove the following packages:
1) bind9-host
2) dnsutils
Accept this solution? [Y/n/q/?] y
The following packages will be REMOVED:
bind9-host{a} dnsutils{a} geoip-database{u} libbind9-60{u} libcap2{u}
libdns66{u} libgeoip1{u}
libgssapi-krb5-2{u} libisc60{u} libisccc60{u} libisccfg60{u}
libk5crypto3{u} libkeyutils1{u} libkrb5-3{u}
libkrb5support0{u} liblwres60{u} libxml2{u} sgml-base{u} xml-core{u}
0 packages upgraded, 0 newly installed, 19 to remove and 67 not upgraded.
Need to get 0B of archives. After unpacking 12.7MB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 14007 files and directories currently installed.)
Removing dnsutils ...
[etc.]
####################################################################
If I had said no, the next option would have been
The following actions will resolve these dependencies:
Upgrade the following packages:
1) bind9-host [1:9.7.1.dfsg.P2-2 (maverick, now) ->
1:9.7.1.dfsg.P2-2ubuntu0.1 (maverick-updates)]
... which is exactly what I wanted, and seems unquestionably the right way
to resolve this dependency. Why isn't this first, and why is the first
solution offered at all?
First off, it seems wrong for "aptitude install" (especially "aptitude -y
install" in a shell script) to ever end up with the package in question
being removed. On an actual Ubuntu system, this is particularly disastrous
because removing dnsutils necessitates removing a dependency of
ubuntu-desktop -- but aptitude seems quite fine with this. We're having an
issue with MIT's Athena install script where if someone installs a
Maverick system from the CD, and then runs our install script without an
update and full-upgrade first, the "aptitude -y install dnsutils" near the
top of the script (right after we run "aptitude update" to pick up our own
repository) will end up with removing most of the system.
Second, "Internal error: found 2 (choice -> promotion) mappings for a
single choice" sounds like it might be problematic. Let me know if there's
debugging information you want; this is fairly easy to reproduce.
Finally, I'm a bit surprised that a solution that involves removing one
package is as "safe" as a solution involving removing your entire
graphical desktop (per the "safety cost levels" metric). I tried tweaking
things like Aptitude::ProblemResolver::Remove-Level=maximum or
Aptitude::ProblemResolver::SolutionCost=safety,removals, which both help,
but they're wrong in cases where you need to remove a single package to
install one that conflicts with it, which, unfortunately, we need to do
later in the install process.
If you're curious, there's some more discussion in our local bug tracker
at http://debathena.mit.edu/trac/ticket/755 .
Let me know if I can provide more information.
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
