<div dir="ltr">Tags: patch<br><div><br>Ah, now I got a proper patch from debdiff. I hadn't gotten aptitude built yet the first time.<br><br></div><div>In actual usage on my system, it suggests upgrades first rather than removals (without any prefs in apt.conf or on the cmdline).<br>
.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 7:56 PM, Chris Tillman <span dir="ltr"><<a href="mailto:toff.tillman@gmail.com" target="_blank">toff.tillman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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>“<span>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><a href="http://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Safe-Level" target="_blank">Aptitude::ProblemResolver::Safe-Level</a></code>, <code><a href="http://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Remove-Level" target="_blank">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<div class="im">
<br>
The following packages will be upgraded: <br></div> 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<div class="im">
<br>
The following packages will be upgraded: <br></div> 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/" target="_blank">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"><div class="im">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>
</div><div><div class="h5"><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><font color="#888888">--<br>
,''`. | Axel Beckert <<a href="mailto:abe@debian.org" target="_blank">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></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Chris Tillman<br>Developer
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Chris Tillman<br>Developer
</div>