<div dir="ltr"><div><div>Tags: patch<br></div><div><br>I think the root of the problem (removing being preferential to upgrading in Aptitude's worldview) is that the safe-level and remove-level default scores are the same.<br>
<br><p class=""><b>Table 2.2. Default safety cost levels</b></p><table summary="Default safety cost levels" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Cost level</th><th>Description</th><th>Configuration option</th>
</tr></thead><tbody><tr><td>10,000</td><td>
                    Solutions that include only <span class="">“<span class="">safe</span>”</span>
                    actions (installing the default target for a
                    package or keeping a package at its current
                    version) and package removals.
                  </td><td><code class=""><a class="" href="http://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Safe-Level">Aptitude::ProblemResolver::Safe-Level</a></code>, <code class=""><a class="" href="http://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Remove-Level">Aptitude::ProblemResolver::Remove-Level</a></code></td>
</tr></tbody></table><br></div>When I use a level just one more than the default for remove-level, I get the desired result:<br><br>121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o 'Aptitude::ProblemResolver::Remove-Level=10000' -vv full-upgrade gir1.2-evince-3.0<br>
The following packages will be upgraded: <br>  gir1.2-evince-3.0 libevdocument3-4 libevview3-3 <br>3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.<br>Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.<br>
The following packages have unmet dependencies:<br> evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be installed.<br>          Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be installed.<br>The following actions will resolve these dependencies:<br>
<br>     Remove the following packages:              <br>1)     evince                                    <br>2)     gnome                                     <br>3)     gnome-core                                <br><br>     Leave the following dependencies unresolved:<br>
4)     epiphany-browser recommends evince        <br><br><br></div>vs.<br><br><br><div><div>121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o 'Aptitude::ProblemResolver::Remove-Level=10001' full-upgrade gir1.2-evince-3.0<br>
The following packages will be upgraded: <br>  gir1.2-evince-3.0 libevdocument3-4 libevview3-3 <br>3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.<br>Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.<br>
The following packages have unmet dependencies:<br> evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be installed.<br>          Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be installed.<br>The following actions will resolve these dependencies:<br>
<br>     Upgrade the following packages:                      <br>1)     evince [3.8.3-2 (now) -> 3.10.0-2 (testing)]       <br>2)     evince-common [3.8.3-2 (now) -> 3.10.0-2 (testing)]<br><br></div><div>I tried to prepare a one-line patch with quilt, as referenced in <br>
<br><a href="http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/">http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/</a><br><br></div><div>but I only got one .dsc file instead of two. I'm attaching that and the patch file quilt generated in debian/patches.<br>
</div><div><br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 10:01 PM, Axel Beckert <span dir="ltr"><<a href="mailto:abe@debian.org" target="_blank">abe@debian.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Vincent Lefevre wrote:<br>
> aptitude sometimes prefers to remove packages instead of upgrading.<br>
<br>
Which is IMHO fine in general. I though must admit that it seems to do<br>
that quite often in Debian Unstable.<br>
<br>
Chris King wrote:<br>
> This is a very annoying behavior<br>
<br>
In Debian Unstable, yes. But it is configurable behaviour, too:<br>
<br>
Use<br>
<br>
  Aptitude::ProblemResolver::Remove-Level "maximum";<br>
<br>
or<br>
<br>
  Aptitude::ProblemResolver::Hints {<br>
          "reject !~M :UNINST";<br>
  };<br>
<br>
in your apt.conf and you're done.<br>
<br>
The latter works better for this issue, but no more allows you to<br>
choose solutions which remove packages unless you explicitly select<br>
them for removal with "-" in the package list or on the commandline.<br>
This can be annoying, too, and is totally unsuited for dist-upgrades<br>
between two stable releases. It hence is _NOT_ a general solution, but<br>
is very suitable for unattended upgrades of security upates.<br>
aptitude-robot uses it for a while now.<br>
<br>
The first variant is probably better suited for general use case, but<br>
can still cause packages to not be upgraded at all due to conflicts<br>
with obosolete packages which actually really should be removed. (I<br>
think, this is one of the reasons why this issue is not trivial to fix<br>
generally without regressions in other fields like dist-upgrades<br>
between two stable releases.)<br>
<br>
> which Aptitude didn't exhibit a year or so ago.<br>
<br>
Hrm, I would be curious which patch introduced that change...<br>
<br>
> Having to hit "n" twenty times before Aptitude decides to upgrade<br>
> one package rather than removing 50 is just silly.<br>
<br>
... and not necessary at all, even without the above configuration.<br>
<br>
Just type "r" on all (often suffices to do it only for some) packages<br>
and hit "." only afterwards. (I don't know by mind the commandline<br>
keybindings for that -- these are for the TUI --  but typing "?" on<br>
the prompt may give you hints.)<br>
<br>
Martin von Wittich wrote:<br>
> Could this be caused by packages that are not marked as automatically<br>
> installed?<br>
<br>
In case of conflicts with newer packages, this is possible. But it's<br>
rather seldom the case according to my experience.<br>
<br>
Chris Tillman wrote:<br>
> I second (3rd? 4th?) this request.<br>
<br>
You're also free to submit a patch!<br>
<br>
                Regards, Axel<br>
<span class="HOEnZb"><font color="#888888">--<br>
 ,''`.  |  Axel Beckert <<a href="mailto:abe@debian.org">abe@debian.org</a>>, <a href="http://people.debian.org/~abe/" target="_blank">http://people.debian.org/~abe/</a><br>
: :' :  |  Debian Developer, <a href="http://ftp.ch.debian.org" target="_blank">ftp.ch.debian.org</a> Admin<br>
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE<br>
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Chris Tillman<br>Developer
</div>