[Aptitude-devel] Bug#559431: cannot upgrade bind9-host with aptitude

[Manuel A. Fernandez Montecelo]

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 at 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 (20000)
>
>Accept this solution? [Y/n/q/?]
>
>root at 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, ignored-recommends, installs

That says to minimize the number of packages kept at their
current version plus twice the number of removals (i.e., a
removal counts for two keeps).  Within that group, ties are
broken by looking at the number of Recommends that were
ignored, and within that group, ties are broken by looking
at the number of new packages the resolver wants to install.

In addition to custom cost vectors, resolver hints can be
used to create completely custom costs.

See the reference manual for full details.

This is not optimized and I expect that pushing it to the
limits will show off all sorts of exponential explosions.
Have fun!
======================


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>