Debian Bug report logs - #570377
aptitude chooses to remove packages instead of upgrading

version graph

Package: aptitude; Maintainer for aptitude is Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>; Source for aptitude is src:aptitude.

Reported by: Vincent Lefevre <vincent@vinc17.net>

Date: Thu, 18 Feb 2010 12:48:02 UTC

Severity: important

Found in version aptitude/0.6.1.5-2

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>:
Bug#570377; Package aptitude. (Thu, 18 Feb 2010 12:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
New Bug report received and forwarded. Copy sent to Daniel Burrows <dburrows@debian.org>. (Thu, 18 Feb 2010 12:48:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: aptitude chooses to remove packages instead of upgrading
Date: Thu, 18 Feb 2010 13:40:29 +0100
Package: aptitude
Version: 0.6.1.5-2
Severity: normal

aptitude sometimes prefers to remove packages instead of upgrading.
For instance:

# aptitude install gstreamer0.10-alsa
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 will be upgraded:
  gstreamer0.10-alsa libgstreamer-plugins-base0.10-0 libgstreamer0.10-0{b} 
3 packages upgraded, 0 newly installed, 0 to remove and 22 not upgraded.
Need to get 1882kB of archives. After unpacking 111kB will be used.
The following packages have unmet dependencies:
  libgstreamer0.10-0: Conflicts: gstreamer0.10-plugins-base (< 0.10.25.2) but 0.10.25-7 is installed and it is kept back.
The following actions will resolve these dependencies:

      Remove the following packages:                           
1)      brasero                                                
2)      cheese                                                 
3)      empathy                                                
4)      gnome-desktop-environment                              
5)      gnome-media                                            
6)      gstreamer0.10-plugins-bad                              
7)      gstreamer0.10-plugins-base                             
8)      gstreamer0.10-plugins-good                             
9)      libempathy-gtk28                                       
10)     libempathy30                                           
11)     libgstfarsight0.10-0                                   
12)     libtelepathy-farsight0                                 
13)     sound-juicer                                           
14)     totem                                                  
15)     totem-coherence                                        
16)     totem-mozilla                                          
17)     totem-plugins                                          

      Leave the following dependencies unresolved:             
18)     gnome-applets recommends gnome-media                   
19)     gnome-media-common recommends gnome-media              
20)     nautilus recommends brasero (>= 2.26)                  
21)     libswfdec-0.8-0 recommends gstreamer0.10-plugins-base  
22)     totem-plugins recommends totem-coherence               
23)     libbrasero-media0 recommends gstreamer0.10-plugins-good
      Tier: Safe actions, Remove packages (10000)              

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

     Upgrade the following packages:                                                
1)     gstreamer0.10-plugins-base [0.10.25-7 (testing, now) -> 0.10.26-1 (unstable)]

     Tier: Safe actions, Remove packages (10000)                                    

Accept this solution? [Y/n/q/?] 
The following packages will be upgraded:
  gstreamer0.10-alsa gstreamer0.10-plugins-base libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 
4 packages upgraded, 0 newly installed, 0 to remove and 21 not upgraded.
Need to get 2610kB of archives. After unpacking 131kB will be used.
Do you want to continue? [Y/n/?] 

It should have chosen the second solution directly (only the first
one is chosen with the user interface).

-- Package-specific info:
aptitude 0.6.1.5 compiled at Feb  3 2010 06:34:23
Compiler: g++ 4.4.3
Compiled against:
  apt version 4.8.0
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20090803
  cwidget version: 0.5.16
  Apt version: 4.8.0
	linux-vdso.so.1 =>  (0x00007fffb23ff000)
	libapt-pkg-libc6.9-6.so.4.8 => /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0x00007f41dbdd9000)
	libncursesw.so.5 => /lib64/libncursesw.so.5 (0x00007f41dbb88000)
	liblog4cxx.so.10 => /usr/lib/liblog4cxx.so.10 (0x00007f41db79a000)
	libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f41db595000)
	libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x00007f41db2c9000)
	libept.so.0 => /usr/lib/libept.so.0 (0x00007f41db051000)
	libxapian.so.15 => /usr/lib/libxapian.so.15 (0x00007f41dad00000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f41daae9000)
	libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f41da85b000)
	libboost_iostreams.so.1.40.0 => /usr/lib/libboost_iostreams.so.1.40.0 (0x00007f41da650000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41da434000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f41da123000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f41d9ea1000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f41d9c8b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f41d9936000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f41d9733000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f41d952f000)
	libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007f41d930b000)
	libdb-4.8.so => /usr/lib/libdb-4.8.so (0x00007f41d8f91000)
	libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f41d8d59000)
	libbz2.so.1.0 => /lib64/libbz2.so.1.0 (0x00007f41d8b48000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f41d8940000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f41dc0b7000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f41d873b000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f41d8504000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f41d82dc000)
Terminal: xterm-debian
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6.9 0.7.25.3         Advanced front-end for dpkg
ii  libboost-iostreams1.40. 1.40.0-6+b1      Boost.Iostreams Library
ii  libc6                   2.10.2-6         Embedded GNU C Library: Shared lib
ii  libcwidget3             0.5.16-3         high-level terminal interface libr
ii  libept0                 0.5.30           High-level library for managing De
ii  libgcc1                 1:4.4.3-2        GCC support library
ii  liblog4cxx10            0.10.0-1.1       A logging library for C++
ii  libncursesw5            5.7+20090803-2   shared libraries for terminal hand
ii  libsigc++-2.0-0c2a      2.2.4.2-1        type-safe Signal Framework for C++
ii  libsqlite3-0            3.6.22-1         SQLite 3 shared library
ii  libstdc++6              4.4.3-2          The GNU Standard C++ Library v3
ii  libxapian15             1.0.18-1         Search engine library
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index              0.23       maintenance tools for a Xapian ind
ii  aptitude-doc-en [aptitude-doc 0.6.1.5-2  English manual for aptitude, a ter
pn  libparse-debianchangelog-perl <none>     (no description available)
ii  sensible-utils                0.0.2      Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags                       <none>     (no description available)
ii  tasksel                       2.81       Tool for selecting tasks for insta

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>:
Bug#570377; Package aptitude. (Tue, 05 Oct 2010 00:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris King <colanderman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Daniel Burrows <dburrows@debian.org>. (Tue, 05 Oct 2010 00:45:03 GMT) Full text and rfc822 format available.

Message #10 received at 570377@bugs.debian.org (full text, mbox):

From: Chris King <colanderman@gmail.com>
To: 570377@bugs.debian.org
Subject: Progress?
Date: Mon, 4 Oct 2010 20:42:54 -0400
Has any progress been made on this bug?  This is a very annoying
behavior which Aptitude didn't exhibit a year or so ago.  Having to
hit "n" twenty times before Aptitude decides to upgrade one package
rather than removing 50 is just silly.




Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>:
Bug#570377; Package aptitude. (Fri, 07 Oct 2011 20:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samuel Bronson <naesten@gmail.com>:
Extra info received and forwarded to list. Copy sent to Daniel Burrows <dburrows@debian.org>. (Fri, 07 Oct 2011 20:42:03 GMT) Full text and rfc822 format available.

Message #15 received at 570377@bugs.debian.org (full text, mbox):

From: Samuel Bronson <naesten@gmail.com>
To: 570377@bugs.debian.org
Cc: Vincent Lefevre <vincent@vinc17.net>, control@bugs.debian.org
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Fri, 07 Oct 2011 16:38:36 -0400
severity 570377 important
thanks

This bug really does make aptitude a lot harder to use for most people,
so I hope this doesn't come across as rude.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!




Severity set to 'important' from 'normal' Request was from Samuel Bronson <naesten@gmail.com> to control@bugs.debian.org. (Fri, 07 Oct 2011 20:42:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Thu, 12 Jul 2012 19:23:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Martin von Wittich <martin.von.wittich@iserv.eu>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>.

Your message did not contain a Subject field. They are recommended and useful because the title of a $gBug is determined using this field. Please remember to include a Subject field in your messages in future.

(Thu, 12 Jul 2012 19:23:05 GMT) Full text and rfc822 format available.


Message #22 received at 570377@bugs.debian.org (full text, mbox):

From: Martin von Wittich <martin.von.wittich@iserv.eu>
To: 570377@bugs.debian.org
Date: Thu, 12 Jul 2012 19:21:34 +0200
[Message part 1 (text/plain, inline)]
Could this be caused by packages that are not marked as automatically
installed? I had this situation on our servers:

# aptitude dist-upgrade -svy > fail.log (see attachedment for output)

After I marked the packages that caused the conflict as automatically
installed:

# aptitude markauto '~nwinst-wnt5-x86-32-driverpack-.*'

And ran the command again:

# aptitude dist-upgrade -svy > success.log (see attachment for output)

aptitude finally did what I expected it to do.

-- 
Mit freundlichen Grüßen,

Martin v. Wittich

IServ GmbH
Rebenring 33
38106 Braunschweig

Telefon:   0531-2243666-0
Fax:       0531-2243666-9
E-Mail:    martin.von.wittich@iserv.eu
Internet:  iserv.eu

USt.-IdNr.:       DE265149425
Registergericht:  Amtsgericht Braunschweig
Registernummer:   HRB 201822
Geschäftsführer:  Jörg Ludwig

[fail.log (text/x-log, attachment)]
[success.log (text/x-log, attachment)]

Information stored :
Bug#570377; Package aptitude. (Mon, 06 Aug 2012 08:15:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and filed, but not forwarded. (Mon, 06 Aug 2012 08:15:13 GMT) Full text and rfc822 format available.

Message #27 received at 570377-quiet@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: 570377-quiet@bugs.debian.org, 672340-quiet@bugs.debian.org, 667750-quiet@bugs.debian.org, 613775-quiet@bugs.debian.org
Subject: debian-reference mentions aptitude regressions
Date: Mon, 6 Aug 2012 16:12:11 +0800
This section:

 2.2.1. apt-get / apt-cache vs. aptitude
 …
 Note
 Although the aptitude command comes with rich features such as
 its enhanced package resolver, this complexity has caused (or
 may still causes) some regressions such as Bug #411123, Bug
 #514930, and Bug #570377. In case of doubt, please use the
 apt-get and apt-cache commands over the aptitude command.

should be updated some time after the regressions have been resolved
in stable.  This is not only for those listed, but others such as
#613775 (causes loss of auto-installed flag) and #672340 (serious
multi-arch issue).



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Thu, 30 Jan 2014 07:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Thu, 30 Jan 2014 07:51:04 GMT) Full text and rfc822 format available.

Message #32 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: 570377@bugs.debian.org
Subject: Held packages
Date: Thu, 30 Jan 2014 20:47:53 +1300
[Message part 1 (text/plain, inline)]
I second (3rd? 4th?) this request. I upgraded to the latest 0.6.8.3 and it
still does the same thing. Choice between 1) 48 removals or 2) 1 upgrade. I
do have a lot of manually held packages as well, so I think Martin von
Wittich might be on the right track. The worst part is that non-experienced
users can trash their system quite easily.

-- 
Chris Tillman
Developer
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Thu, 30 Jan 2014 09:03:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Thu, 30 Jan 2014 09:03:10 GMT) Full text and rfc822 format available.

Message #37 received at 570377@bugs.debian.org (full text, mbox):

From: Axel Beckert <abe@debian.org>
To: 570377@bugs.debian.org
Cc: Chris Tillman <toff.tillman@gmail.com>, Martin von Wittich <martin.von.wittich@iserv.eu>, Vincent Lefevre <vincent@vinc17.net>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Thu, 30 Jan 2014 10:01:58 +0100
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 <abe@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



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Sat, 01 Feb 2014 08:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Sat, 01 Feb 2014 08:12:04 GMT) Full text and rfc822 format available.

Message #42 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: 570377@bugs.debian.org
Subject: More information
Date: Sat, 1 Feb 2014 21:09:11 +1300
[Message part 1 (text/plain, inline)]
I found that adding the apt.conf option

Aptitude::Always-Use-Safe-Resolver "true";

results in aptitude selecting the upgrade rather than the removal, but ONLY
command-line aptitude. command-line obeys apt.conf, even disregarding the
command-line "full-upgrade" invocation.

On the other hand, TUI aptitude seems to have disregarded apt.conf; this
may be related to bug
#485832<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485832>
.

I will continue to look for the root cause and a desirable solution.

-- 
Chris Tillman
Developer
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Sun, 02 Feb 2014 07:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Sun, 02 Feb 2014 07:00:04 GMT) Full text and rfc822 format available.

Message #47 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: 570377@bugs.debian.org
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Sun, 2 Feb 2014 19:56:44 +1300
[Message part 1 (text/plain, inline)]
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 <abe@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 <abe@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
[Message part 2 (text/html, inline)]
[aptitude_0.6.8.3-1.dsc (application/octet-stream, attachment)]
[fix-aptitude-remove-priority (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Sun, 02 Feb 2014 08:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Sun, 02 Feb 2014 08:27:04 GMT) Full text and rfc822 format available.

Message #52 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: 570377@bugs.debian.org
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Sun, 2 Feb 2014 21:23:56 +1300
[Message part 1 (text/plain, inline)]
Tags: patch

Ah, now I got a proper patch from debdiff. I hadn't gotten aptitude built
yet the first time.

In actual usage on my system, it suggests upgrades first rather than
removals (without any prefs in apt.conf or on the cmdline).
.


On Sun, Feb 2, 2014 at 7:56 PM, Chris Tillman <toff.tillman@gmail.com>wrote:

> 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 option 10,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 <abe@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 <abe@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
>



-- 
Chris Tillman
Developer
[Message part 2 (text/html, inline)]
[aptitude-patch-remove-priority.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Mon, 03 Feb 2014 17:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Mon, 03 Feb 2014 17:33:04 GMT) Full text and rfc822 format available.

Message #57 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org
Cc: Martin von Wittich <martin.von.wittich@iserv.eu>, Vincent Lefevre <vincent@vinc17.net>, Chris King <colanderman@gmail.com>
Subject: Re: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 01:29:30 +0800
On 2 February 2014 14:56, Chris Tillman <toff.tillman@gmail.com> wrote:
>
> 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.
>

Hi

Thanks for your interest and patch.  Unfortunately, it is not an
acceptable solution to apply to the _default_ settings.

There is nothing fundamentally better or worse about either removals
or installs, in some situations you might find this:

 solution 1: upgrade 20 packages
 solution 2: remove 1

Whichever is more preferable in these situations is up to the
individual user to decide based on whatever particular packages are
suggested for upgrade, install, or removal—aptitude can not know how
the user values those individual actions.  The point of the safety
cost _levels_ is to broadly class categories of actions, and in that
sense, installing or upgrading to a package in the target release is
no better or worse than removing a non-essential package.

Tweaking the default settings as per the patch here is not to be done
lightly.  Considering the architecture of the problem resolver as a
whole, it is not an acceptable solution.

I recommend any of Axels suggestions for individual users who are
bothered by this, especially the comments about guiding the resolver
by e.g. rejecting particular actions _before_ asking for the next
solution.  This is also covered in the users manual, _Resolving
Dependencies Interactively_.  That is the most effective way of
informing the resolver about your desires.

Regards



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 02:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 02:18:04 GMT) Full text and rfc822 format available.

Message #62 received at 570377@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Axel Beckert <abe@debian.org>
Cc: 570377@bugs.debian.org, Chris Tillman <toff.tillman@gmail.com>, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 03:15:53 +0100
On 2014-01-30 10:01:58 +0100, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > aptitude sometimes prefers to remove packages instead of upgrading.
> 
> Which is IMHO fine in general.

I don't see why it would be fine. Upgrading (to satisfy the
dependencies) should always be favored. There could be exceptions in
theory, but I don't think they would occur in practice. I think that
the upgrade vs remove problem occurs because of "=" dependencies,
and an upgrade of some package should also upgrade by default the
corresponding packages with a "=" dependency instead of removing
them.

> 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 is unacceptable: some packages may be safe to remove
automatically, e.g. old libraries, and sometimes the only
solution is to remove them. The user shouldn't be forced to
do anything special.

> 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.

This doesn't really apply to unstable.

> 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.

Yes.

> (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.)

Well, apt-get does a better job than aptitude in general.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 02:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 02:27:05 GMT) Full text and rfc822 format available.

Message #67 received at 570377@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Daniel Hartwig <mandyke@gmail.com>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 03:24:16 +0100
On 2014-02-04 01:29:30 +0800, Daniel Hartwig wrote:
> There is nothing fundamentally better or worse about either removals
> or installs, in some situations you might find this:
> 
>  solution 1: upgrade 20 packages
>  solution 2: remove 1
> 
> Whichever is more preferable in these situations is up to the
> individual user to decide based on whatever particular packages are
> suggested for upgrade, install, or removal—aptitude can not know how
> the user values those individual actions.

Could you explain why, e.g. by giving a practical example?

Because I would say: A remove can be caused by some obsolete package
due to a conflict with the newly installed package (or one of its
dependencies). But in such a case, the remove would occur in *every*
solution. If a package is not obsolete, aptitude should never propose
it for removal when another solution can solve the problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 02:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 02:36:05 GMT) Full text and rfc822 format available.

Message #72 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org
Subject: Re: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 10:33:36 +0800
The safety cost levels are not intended to fine tune the results.
They are a broad base to start from.  There are other parameters for
Aptitude::ProblemResolver::SolutionCost to provide tweaking (e.g. "3 *
removals + installs").  Details are in the manual, where I think it is
quite clear.

More details follow.

On 4 February 2014 02:10, Chris Tillman <toff.tillman@gmail.com> wrote:
> Thanks very much for your reply and explanation, Daniel. I can appreciate
> that fiddling with defaults is a serious consideration. However, the scoring
> system replaced the tiered system where removals were considered less
> desirable than upgrades. So longtime users perceived a drastic change in
> behaviour and in aptitude's "attitude".
>
> I don't know why, with equal scores, aptitude now prefers the removals
> option. Even with 3 to remove or 2 to upgrade, it still suggests the
> removals first.

The default setup is not configured to compare the number of removals
vs upgrades.  You can adjust Aptitude::ProblemResolver::SolutionCost
to something like "safety, removals" if you care to fine tune as such.

Changing something like that is more desirable (I explain later about
safety cost levels), but requires people to change their own settings,
use it for some time, and provide feedback before any change to the
defaults will be considered.

> By adjusting the default just one point, its behaviour was
> completely different and it became a pleasure to use rather than seeming a
> constant battle. There may not be a philosophical difference between
> recommending removal of 3 packages including "gnome", vs. upgrading 2
> packages including the one you asked to upgrade, but there is definitely a
> psychological difference. So I'd argue that the 1-point advantage given to
> upgrades would represent that psychological preference.
>
> I really wonder about even the philosophical difference being 0. Users are
> attempting to maintain their system. If a user asks for an install or
> upgrade, surely more upgrades would be preferable. If they are doing
> removals or downgrades, then perhaps removals would be the direction they
> would want to go. Perhaps aptitude could be more sensitive to the requested
> operation and adjust priorities accordingly. Would you be open to a patch
> for that?
>

No, as this makes the program less predictable.  Also, many sets of
user requests are not exclusively upgrades, installs, or removals,
sessions are often a mixture of these.

> And, in any case, I certainly can't understand why the defaults chosen
> should be carved in stone. 10000, 20000, 50000 ... these seem to have been
> set nearly arbitrarily. Do we have any data about real-world user actions,
> i.e. x choices presented in scored order and score[i] actually chosen, that
> would allow us to zero in on truly representative weights which minimise i?
>

The safety cost _levels_ are set so as to provide a broad base from
which to work.  There are additional settings you can use in
Aptitude::ProblemResolver::SolutionCost to provide fine tuning based
on the number of removals vs. installs, etc..  The reason for the
large spacing of the _levels_ is to permit enough room for the other
costs to tweak the situation according to users tastes, e.g. weighing
a solution with 3 removals as less desirable than 2 upgrades.

With the change you propose—and only that—then _any_ solution with
removals will be weighed after all solutions of installs/upgrades (to
default release), even if it is a single solution of 1 removal vs
dozens of solutions with hundreds of installs.  This is not a
desirable default.

You can tweak the settings on your machine in different ways, using
each for a while to get a proper feel.  Some feedback based on long
term use of different settings would be useful.



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 02:51:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 02:51:10 GMT) Full text and rfc822 format available.

Message #77 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 10:49:53 +0800
On 4 February 2014 10:24, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2014-02-04 01:29:30 +0800, Daniel Hartwig wrote:
>> There is nothing fundamentally better or worse about either removals
>> or installs, in some situations you might find this:
>>
>>  solution 1: upgrade 20 packages
>>  solution 2: remove 1
>>
>> Whichever is more preferable in these situations is up to the
>> individual user to decide based on whatever particular packages are
>> suggested for upgrade, install, or removal—aptitude can not know how
>> the user values those individual actions.
>
> Could you explain why, e.g. by giving a practical example?
>

In my prior response, I am only addressing the proposed patch to tweak
the safety cost levels.  As the manual explains, the safety cost
levels are meant to be broad--a base on which further tweaking can be
provided.  There are additional operators, such as "removals" and
"installs" that can be inserted in to the safety cost calculation and
provide tweaking.

So my comments about the two being equivalent are only at the scope of
the _safety cost levels_.

> Because I would say: A remove can be caused by some obsolete package
> due to a conflict with the newly installed package (or one of its
> dependencies). But in such a case, the remove would occur in *every*
> solution. If a package is not obsolete, aptitude should never propose
> it for removal when another solution can solve the problem.
>

That is not the results from the current problem resolver, removals
often pop up in isolated solutions, including different solutions with
different removals.  I do not know why that happens, however, given
that it does, the proposed change to safety levels will dismiss some
potentially trivial, very short solutions (e.g. 1 removal) in favour
of dozens or more solutions that install/upgrade hundreds of packages
each.

Again, I am only addressing the proposed patch.  There are better
options, such as adjusting the default value of
Aptitude::ProblemResolver::SolutionCost to account for the number of
removals vs installs, or similar, but people should use such settings
and provide feedback on the quality of the solutions and their order.



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 03:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 03:57:05 GMT) Full text and rfc822 format available.

Message #82 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: 570377@bugs.debian.org
Cc: Chris Tillman <toff.tillman@gmail.com>, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>, Vincent Lefevre <vincent@vinc17.net>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 11:55:49 +0800
To begin chasing down a real, workable solution:

The default SolutionCost is "safety, priority".  I suspect the main
problem here may be due to the unintended interactions of "priority"
when there are/aren't removals involved, but do not have time to
investigate further just yet *hint*.



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 04:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 04:15:04 GMT) Full text and rfc822 format available.

Message #87 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: 570377@bugs.debian.org
Subject: Fwd: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 17:10:53 +1300
[Message part 1 (text/plain, inline)]
Thanks very much for your reply and explanation, Daniel. I can appreciate
that fiddling with defaults is a serious consideration. However, the
scoring system replaced the tiered system where removals were considered
less desirable than upgrades. So longtime users perceived a drastic change
in behaviour and in aptitude's "attitude".

I don't know why, with equal scores, aptitude now prefers the removals
option. Even with 3 to remove or 2 to upgrade, it still suggests the
removals first. By adjusting the default just one point, its behaviour was
completely different and it became a pleasure to use rather than seeming a
constant battle. There may not be a philosophical difference between
recommending removal of 3 packages including "gnome", vs. upgrading 2
packages including the one you asked to upgrade, but there is definitely a
psychological difference. So I'd argue that the 1-point advantage given to
upgrades would represent that psychological preference.

I really wonder about even the philosophical difference being 0. Users are
attempting to maintain their system. If a user asks for an install or
upgrade, surely more upgrades would be preferable. If they are doing
removals or downgrades, then perhaps removals would be the direction they
would want to go. Perhaps aptitude could be more sensitive to the requested
operation and adjust priorities accordingly. Would you be open to a patch
for that?

And, in any case, I certainly can't understand why the defaults chosen
should be carved in stone. 10000, 20000, 50000 ... these seem to have been
set nearly arbitrarily. Do we have any data about real-world user actions,
i.e. x choices presented in scored order and score[i] actually chosen, that
would allow us to zero in on truly representative weights which minimise i?

Thanks,
Chris




On Tue, Feb 4, 2014 at 6:29 AM, Daniel Hartwig <mandyke@gmail.com> wrote:

> On 2 February 2014 14:56, Chris Tillman <toff.tillman@gmail.com> wrote:
> >
> > 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.
> >
>
> Hi
>
> Thanks for your interest and patch.  Unfortunately, it is not an
> acceptable solution to apply to the _default_ settings.
>
> There is nothing fundamentally better or worse about either removals
> or installs, in some situations you might find this:
>
>  solution 1: upgrade 20 packages
>  solution 2: remove 1
>
> Whichever is more preferable in these situations is up to the
> individual user to decide based on whatever particular packages are
> suggested for upgrade, install, or removal--aptitude can not know how
> the user values those individual actions.  The point of the safety
> cost _levels_ is to broadly class categories of actions, and in that
> sense, installing or upgrading to a package in the target release is
> no better or worse than removing a non-essential package.
>
> Tweaking the default settings as per the patch here is not to be done
> lightly.  Considering the architecture of the problem resolver as a
> whole, it is not an acceptable solution.
>
> I recommend any of Axels suggestions for individual users who are
> bothered by this, especially the comments about guiding the resolver
> by e.g. rejecting particular actions _before_ asking for the next
> solution.  This is also covered in the users manual, _Resolving
> Dependencies Interactively_.  That is the most effective way of
> informing the resolver about your desires.
>
> Regards
>



-- 
Chris Tillman
Developer



-- 
Chris Tillman
Developer
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 11:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 11:57:04 GMT) Full text and rfc822 format available.

Message #92 received at 570377@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Daniel Hartwig <mandyke@gmail.com>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Tue, 4 Feb 2014 12:53:01 +0100
On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:
> On 4 February 2014 10:24, Vincent Lefevre <vincent@vinc17.net> wrote:
> > Because I would say: A remove can be caused by some obsolete package
> > due to a conflict with the newly installed package (or one of its
> > dependencies). But in such a case, the remove would occur in *every*
> > solution. If a package is not obsolete, aptitude should never propose
> > it for removal when another solution can solve the problem.
> >
> 
> That is not the results from the current problem resolver, removals
> often pop up in isolated solutions, including different solutions with
> different removals.  I do not know why that happens, however, given
> that it does, the proposed change to safety levels will dismiss some
> potentially trivial, very short solutions (e.g. 1 removal) in favour
> of dozens or more solutions that install/upgrade hundreds of packages
> each.

But removing a package providing a useful application is not a
satisfactory solution. And having to upgrade hundreds of packages
(which is quite rare) is not a problem since this is what users
should eventually do, for various reasons (security...). So, the
size of the solution is not a good criterion.

> Again, I am only addressing the proposed patch.  There are better
> options, such as adjusting the default value of
> Aptitude::ProblemResolver::SolutionCost to account for the number of
> removals vs installs, or similar, but people should use such settings
> and provide feedback on the quality of the solutions and their order.

It would be better if aptitude could tell the reasons that led to the
proposed solution.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Tue, 04 Feb 2014 16:57:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Tue, 04 Feb 2014 16:57:17 GMT) Full text and rfc822 format available.

Message #97 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Wed, 5 Feb 2014 00:56:26 +0800
On 4 February 2014 19:53, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:
>> Again, I am only addressing the proposed patch.  There are better
>> options, such as adjusting the default value of
>> Aptitude::ProblemResolver::SolutionCost to account for the number of
>> removals vs installs, or similar, but people should use such settings
>> and provide feedback on the quality of the solutions and their order.
>
> It would be better if aptitude could tell the reasons that led to the
> proposed solution.

Do you mean:

 --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2)
    -> Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)]
  --\ openjdk-6-jre depends upon libjpeg8
    -> Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)]

?



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Wed, 05 Feb 2014 22:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Wed, 05 Feb 2014 22:39:05 GMT) Full text and rfc822 format available.

Message #102 received at 570377@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Daniel Hartwig <mandyke@gmail.com>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Wed, 5 Feb 2014 23:37:32 +0100
On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote:
> On 4 February 2014 19:53, Vincent Lefevre <vincent@vinc17.net> wrote:
> > On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:
> >> Again, I am only addressing the proposed patch.  There are better
> >> options, such as adjusting the default value of
> >> Aptitude::ProblemResolver::SolutionCost to account for the number of
> >> removals vs installs, or similar, but people should use such settings
> >> and provide feedback on the quality of the solutions and their order.
> >
> > It would be better if aptitude could tell the reasons that led to the
> > proposed solution.
> 
> Do you mean:
> 
>  --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2)
>     -> Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)]
>   --\ openjdk-6-jre depends upon libjpeg8
>     -> Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)]
> 
> ?

Something like that. Perhaps that's what the -v --show-why options do.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Thu, 06 Feb 2014 02:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Hartwig <mandyke@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Thu, 06 Feb 2014 02:33:05 GMT) Full text and rfc822 format available.

Message #107 received at 570377@bugs.debian.org (full text, mbox):

From: Daniel Hartwig <mandyke@gmail.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Chris Tillman <toff.tillman@gmail.com>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Thu, 6 Feb 2014 10:31:03 +0800
On 6 February 2014 06:37, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote:
>> On 4 February 2014 19:53, Vincent Lefevre <vincent@vinc17.net> wrote:
>> > On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:
>> >> Again, I am only addressing the proposed patch.  There are better
>> >> options, such as adjusting the default value of
>> >> Aptitude::ProblemResolver::SolutionCost to account for the number of
>> >> removals vs installs, or similar, but people should use such settings
>> >> and provide feedback on the quality of the solutions and their order.
>> >
>> > It would be better if aptitude could tell the reasons that led to the
>> > proposed solution.
>>
>> Do you mean:
>>
>>  --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2)
>>     -> Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)]
>>   --\ openjdk-6-jre depends upon libjpeg8
>>     -> Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)]
>>
>> ?
>
> Something like that. Perhaps that's what the -v --show-why options do.
>

Use 'o' when examining a solution in the curses interface.  On the
command line, set Aptitude::CmdLine::Resolver-Show-Steps=1.



Information forwarded to debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:
Bug#570377; Package aptitude. (Sat, 08 Feb 2014 06:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Chris Tillman <toff.tillman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>. (Sat, 08 Feb 2014 06:48:05 GMT) Full text and rfc822 format available.

Message #112 received at 570377@bugs.debian.org (full text, mbox):

From: Chris Tillman <toff.tillman@gmail.com>
To: Daniel Hartwig <mandyke@gmail.com>
Cc: Vincent Lefevre <vincent@vinc17.net>, 570377@bugs.debian.org, Martin von Wittich <martin.von.wittich@iserv.eu>, Chris King <colanderman@gmail.com>
Subject: Re: Bug#570377: aptitude chooses to remove packages instead of upgrading
Date: Sat, 8 Feb 2014 19:45:11 +1300
[Message part 1 (text/plain, inline)]
So, regarding Aptitude::ProblemResolver::SolutionCost ; in your development
missive of 2010-04-10 07:17 you say

"safety, priority"  should give you the behavior of 0.6.1.5-3 (and is
thus the default).


So, I tried a couple things on a package that would require either two
upgrades or 3 removals (and where I would prefer the upgrades be offered
first). In the default mode, with safe-upgrade I get the upgrades offered;
and with full-upgrade I get the removals offered first and then the
upgrades.

Setting it to "priority, safety" gives us the upgrades first, but then some
terribly complex solutions involving nearly 70 packages and leaving 17
dependencies unresolved.

Setting it to just "safety" does what I want, offering 2 upgrades and then
3 removals.

How about "safety * 10, priority" then? No, same result as just safety,
priority. "safety * 1000, priority" then? Same result. Same if the factor
even goes to 10000 or 100000 (though on 100000 I did get a bonus error
apparently because 5 digits is the most expected: "Failed to parse the cost
settings string: <none>:1:8: Expected EOF, got '*'.". So what gives there?
Why does adding priority as a second stage upset the apple cart no matter
how much I emphasise safety?

OK, so reset and let's try something different. I'm getting offered 3
removals or 2 upgrades. (BTW, the package is the recently-upgradeable
libgcr-3-1, the removals offered are "gnome, libgcr-3-1, seahorse" and the
upgrades offered are "libgcr-3-1, libgcr-ui-3-1". Basically any
non-brain-dead person can see what's better here, so that's why I want
aptitude to see things our way.

How about working with removals and upgrades, since that's what's on offer
in this situation? I guess theoretically according the FM, if we make
removals cost twice what upgrades do, then the upgrades should move ahead
since our ratio is 3 to 2.

I tried "removals * 2, upgrades" ... this still offered me the removals
first. I tried "removals * 2 + upgrades" ... still no joy. Changing the
factor to 10 or 1000 still made no difference. Going back the manual, I see
one of the examples offered is simply "removals" ... this should mean
"solutions
with fewer removals always appear before solutions with more removals".
Well, that does make a difference. I get the upgrades offered first, then
after some gnashing, the cancellation option. Removals offered as the third
option.

Hmmm, not much chance of Daniel accepting a default of "removals" rather
than "safety, priority" though. Let's try something else. Hey, I wonder if
addition is commutative in aptitude's world? Let's try "upgrades + removals
* 2" ... yes this still offers removals first, same with a factor of 1000.
But is multiplication commutative? Not in this case, "upgrades + 2 *
removals" gives a completely different outcome ... cancellation as the
first option, then upgrades, and finally removals.

Here's a potential winner: "safety, removals" ... this gives me the desired
outcome in this case; upgrades offered first, then removals, then
cancellation. In fact, just _adding_ removals as in "safety, priority,
removals" also gives me the desired result. The only thing is, aptitude
seems to work much harder (is much slower, and shows the open: closed:
defer: conflict: statistics in the command line output) to achieve the
answer in this case. It's not consistent to me, that adding a third sort
level should affect the outcome here. Well, I have to say, the whole cost
system is not very easy for users to comprehend and use. How many will take
the time to actually try to adjust costs to their liking? Very very few I
warrant, and especially when the effect of reasonable guesses such as above
is not particularly predictable.

OK, so my proposal is to set the default SolutionCost to "safety, removals"
or else "safety, priority, removals", figure out what the performance
problems are with these and resolve them before releasing. You suggested
adjusting the default SolutionCost Daniel, rather than the default safety
cost for removals, which to me is a much better way of stating that we like
removals slightly less than we like install-default or keep. How about it?

Chris



On Thu, Feb 6, 2014 at 3:31 PM, Daniel Hartwig <mandyke@gmail.com> wrote:

> On 6 February 2014 06:37, Vincent Lefevre <vincent@vinc17.net> wrote:
> > On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote:
> >> On 4 February 2014 19:53, Vincent Lefevre <vincent@vinc17.net> wrote:
> >> > On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:
> >> >> Again, I am only addressing the proposed patch.  There are better
> >> >> options, such as adjusting the default value of
> >> >> Aptitude::ProblemResolver::SolutionCost to account for the number of
> >> >> removals vs installs, or similar, but people should use such settings
> >> >> and provide feedback on the quality of the solutions and their order.
> >> >
> >> > It would be better if aptitude could tell the reasons that led to the
> >> > proposed solution.
> >>
> >> Do you mean:
> >>
> >>  --\ icedtea6-plugin depends upon openjdk-6-jre (=
> 6b18-1.8.13-0+squeeze2)
> >>     -> Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)]
> >>   --\ openjdk-6-jre depends upon libjpeg8
> >>     -> Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)]
> >>
> >> ?
> >
> > Something like that. Perhaps that's what the -v --show-why options do.
> >
>
> Use 'o' when examining a solution in the curses interface.  On the
> command line, set Aptitude::CmdLine::Resolver-Show-Steps=1.
>



-- 
Chris Tillman
Developer
[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 16:19:23 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.