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