Control: tags -1 + moreinfo
Hi Vincent,
2009-12-04 11:23 Vincent Lefevre:
Package: aptitude
Version: 0.6.1.3-3
Severity: normal
I cannot upgrade bind9-host with aptitude, whereas this is
possible with apt-get:
root@vin:/home/vlefevre# aptitude install bind9-host
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
dnsutils libdns50
The following NEW packages will be installed:
libdns53{a}
The following packages will be upgraded:
bind9-host libbind9-50 libisc50 libisccc50 libisccfg50 liblwres50
6 packages upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 1,049kB of archives. After unpacking 1,602kB will be used.
The following packages have unmet dependencies:
dnsutils: Depends: libbind9-50 (= 1:9.6.1.dfsg.P1-3) but 1:9.6.1.dfsg.P2-1 is
to be installed.
Depends: libisc50 (= 1:9.6.1.dfsg.P1-3) but 1:9.6.1.dfsg.P2-1 is to
be installed.
Depends: libisccfg50 (= 1:9.6.1.dfsg.P1-3) but 1:9.6.1.dfsg.P2-1 is
to be installed.
Depends: liblwres50 (= 1:9.6.1.dfsg.P1-3) but 1:9.6.1.dfsg.P2-1 is
to be installed.
libdns50: Depends: libisc50 (= 1:9.6.1.dfsg.P1-3) but 1:9.6.1.dfsg.P2-1 is to
be installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
bind9-host [1:9.6.1.dfsg.P1-3 (now)]
libbind9-50 [1:9.6.1.dfsg.P1-3 (now)]
libdns53 [Not Installed]
libisc50 [1:9.6.1.dfsg.P1-3 (now)]
libisccc50 [1:9.6.1.dfsg.P1-3 (now)]
libisccfg50 [1:9.6.1.dfsg.P1-3 (now)]
liblwres50 [1:9.6.1.dfsg.P1-3 (now)]
Tier: Cancel all user actions (2)
Accept this solution? [Y/n/q/?]
root@vin:/home/vlefevre# apt-get install -s bind9-host
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
dnsutils libbind9-50 libdns53 libisc50 libisccc50 libisccfg50 liblwres50
Suggested packages:
rblcheck
The following packages will be REMOVED:
libdns50
The following NEW packages will be installed:
libdns53
The following packages will be upgraded:
bind9-host dnsutils libbind9-50 libisc50 libisccc50 libisccfg50 liblwres50
7 upgraded, 1 newly installed, 1 to remove and 44 not upgraded.
Inst bind9-host [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst dnsutils [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst libbind9-50 [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst libisccfg50 [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst libisccc50 [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Remv libdns50 [1:9.6.1.dfsg.P1-3] []
Inst libisc50 [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst libdns53 (1:9.6.1.dfsg.P2-1 Debian:unstable) []
Inst liblwres50 [1:9.6.1.dfsg.P1-3] (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf libisc50 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf libdns53 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf libisccc50 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf libisccfg50 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf libbind9-50 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf liblwres50 (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf bind9-host (1:9.6.1.dfsg.P2-1 Debian:unstable)
Conf dnsutils (1:9.6.1.dfsg.P2-1 Debian:unstable)
Sorry that this report was not handled until now.
There are still similar problems with current versions of aptitude in
the default configuration -- the first suggestion of aptitude often
prefers to keep packages requested to install/upgrade uninstalled or at
the same version, or even remove them, rather than install/upgrade the
necessary dependencies. And there are multiple reports about the
different manifestations of the current problem.
I am wondering if it's better to close this particular bug report
though, rather than merge; because judging by the time, version and the
message, the resolver implementation at that time (based on "Tiers") was
different than what it is used now, so in my opinion it doesn't even
make sense to try to reproduce the behaviour which caused this problem,
and keeping it open doesn't help to investigate the problems with the
current implementation that we should attempt to fix.
This is the relevant explanation from the changelog of version of 0.6.2
(version released shortly after the one that you were using):
==
[2010-04-18]
Version 0.6.2 "A costly proposition"
- New features:
+ [all] Resolver tiers are dead, long live resolver costs.
The resolver now supports a flexible system of multi-leveled
costs, in place of the fairly rigid tiers of previous
releases. The default behavior emulates how tiers worked,
but the resolver can also be configured with custom cost
vectors by setting Aptitude::ProblemResolver::SolutionCost
to something like this:
canceled-actions + 2*removals,
