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
Merged with 600600
Found in version aptitude/0.6.1.5-2
Fixed in version aptitude/0.8-1
Done: mafm@debian.org (Manuel A. Fernandez Montecelo)
Bug is archived. No further changes may be made.
View this report as an mbox folder, status mbox, maintainer mbox
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.Vincent Lefevre <vincent@vinc17.net>: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, reply):
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
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.Chris King <colanderman@gmail.com>: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, reply):
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.
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.Samuel Bronson <naesten@gmail.com>: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, reply):
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!
Samuel Bronson <naesten@gmail.com>
to control@bugs.debian.org.
(Fri, 07 Oct 2011 20:42:05 GMT) Full text and rfc822 format available.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.Martin von Wittich <martin.von.wittich@iserv.eu>: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, reply):
[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)]
Bug#570377; Package aptitude.
(Mon, 06 Aug 2012 08:15:13 GMT) Full text and rfc822 format available.Daniel Hartwig <mandyke@gmail.com>:Message #27 received at 570377-quiet@bugs.debian.org (full text, mbox, reply):
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).
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
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.Axel Beckert <abe@debian.org>: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, reply):
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
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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
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.Vincent Lefevre <vincent@vinc17.net>: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, reply):
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)
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.Vincent Lefevre <vincent@vinc17.net>: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, reply):
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)
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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.
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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.
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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*.
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
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.Vincent Lefevre <vincent@vinc17.net>: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, reply):
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)
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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)]
?
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.Vincent Lefevre <vincent@vinc17.net>: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, reply):
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)
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.Daniel Hartwig <mandyke@gmail.com>: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, reply):
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.
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.Chris Tillman <toff.tillman@gmail.com>: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, reply):
[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)]
debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:Bug#570377; Package aptitude.
(Sun, 08 Jun 2014 22:48:05 GMT) Full text and rfc822 format available.Message #115 received at 570377@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sb, 08 feb 14, 19:45:11, Chris Tillman wrote:
>
> 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?
Your proposal is definitely an improvement, however:
# LANG=C aptitude full-upgrade
The following packages will be upgraded:
libldb1
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 109 kB of archives. After unpacking 27.6 kB will be freed.
The following packages have unmet dependencies:
samba-libs : Depends: libldb1 (< 1:1.1.17~) but 1:1.1.17-1 is to be installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) gvfs-backends
2) kde-runtime
3) konsole
4) krusader
5) libsmbclient
6) lokalize
7) mplayer2
8) phonon-backend-vlc
9) samba-libs
10) smplayer
11) smplayer-l10n
12) vlc
13) vlc-nox
14) vlc-plugin-notify
15) vlc-plugin-vlsub
16) xbmc
17) xbmc-bin
Leave the following dependencies unresolved:
18) gnome-bluetooth recommends gvfs-backends
19) kdelibs5-plugins recommends kde-runtime
20) pacpl recommends mplayer
21) pcmanfm recommends gvfs-backends
22) tuxcmd-modules recommends gvfs-backends
23) youtube-dl recommends mplayer2 | mplayer
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) libldb1 [1:1.1.16-1 (now, testing)]
Accept this solution? [Y/n/q/?] y
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
I tried the default, "safety,priority,removals", "safety,removals", but
only "removals" comes up with the correct solution:
# LANG=C aptitude full-upgrade
The following packages will be upgraded:
libldb1
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 109 kB of archives. After unpacking 27.6 kB will be freed.
The following packages have unmet dependencies:
samba-libs : Depends: libldb1 (< 1:1.1.17~) but 1:1.1.17-1 is to be installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) libldb1 [1:1.1.16-1 (now, testing)]
Accept this solution? [Y/n/q/?] y
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
[signature.asc (application/pgp-signature, inline)]
debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:Bug#570377; Package aptitude.
(Sun, 11 Oct 2015 08:39:03 GMT) Full text and rfc822 format available.Chris Tillman <toff.tillman@gmail.com>:Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>.
(Sun, 11 Oct 2015 08:39:03 GMT) Full text and rfc822 format available.Message #120 received at 570377@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
I bought a new (used) computer, and installed a new system. This annoying behaviour came back, of course, because I had set the old one up to get rid of it. For anyone being affected by these bugs, or annoyed by removals being offered first, I'd suggest trying this in your ~/.aptitude/config file: Aptitude ""; Aptitude::ProblemResolver ""; Aptitude::ProblemResolver::Remove-Level "10001"; In any case, it was more than a little humorous that the issue affected aptitude itself, when I asked for it to upgrade from jessie to testing. It proposed removal of itself. The problem was apparently that synaptic hasn't yet been updated to be compatible with the new aptitude. So attempting to upgrade aptitude simply didn't work as long as synaptic was installed. Preferring aptitude to synaptic, I removed the latter. I'd also like to take this opportunity to list other open, very probably related bugs. If nothing else, the number of these bugs is testament to how many people are shocked that removal is offered before upgrade. Daniel, you may think removals are "theoretically" equivalent to upgrades, and that's fine, but many, many users favor upgrades. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798240 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762932 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757440 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755391 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731318 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724032 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722211 <-- where Axel acknowledges the behaviour as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678832 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671486 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663134 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653284 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643997 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610845 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591892 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588202 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574132 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568548 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565760 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542264 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540978 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514348 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502766 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453935 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444831 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437291 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419501 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401994 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365644 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346321 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342835 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341963 So, I believe many birds could be killed with just one carefully selected stone (the originally submitted patchj. Here's my example du jour. With default ( Aptitude::ProblemResolver::Remove-Level "10000"; ) out only option os to remove. [image: Inline image 2] With the suggested change ( Aptitude::ProblemResolver::Remove-Level "10001"; ) our only option is to upgrade. [image: Inline image 3] I attached the two trace files from those small sessions as well. -- Chris Tillman Developer
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]
[image.png (image/png, inline)]
[aptitude.trace.10001 (application/octet-stream, attachment)]
[aptitude.trace.default-setting (application/octet-stream, attachment)]
debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:Bug#570377; Package aptitude.
(Sun, 11 Oct 2015 09:09:03 GMT) Full text and rfc822 format available.Vincent Lefevre <vincent@vinc17.net>:Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>.
(Sun, 11 Oct 2015 09:09:03 GMT) Full text and rfc822 format available.Message #125 received at 570377@bugs.debian.org (full text, mbox, reply):
On 2015-10-11 21:36:19 +1300, Chris Tillman wrote: > I bought a new (used) computer, and installed a new system. This annoying > behaviour came back, of course, because I had set the old one up to get rid > of it. > > For anyone being affected by these bugs, or annoyed by removals being > offered first, I'd suggest trying this in your ~/.aptitude/config file: > > Aptitude ""; > Aptitude::ProblemResolver ""; > Aptitude::ProblemResolver::Remove-Level "10001"; [...] In https://lists.debian.org/debian-user/2014/07/msg00398.html Andrei POPESCU suggested: Aptitude::ProblemResolver::SolutionCost "removals"; but this can lead to downgrades: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762932 How does your solution behave compared to this one? -- 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)
debian-bugs-dist@lists.debian.org, Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>:Bug#570377; Package aptitude.
(Sun, 11 Oct 2015 18:33:03 GMT) Full text and rfc822 format available.Chris Tillman <toff.tillman@gmail.com>:Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>.
(Sun, 11 Oct 2015 18:33:04 GMT) Full text and rfc822 format available.Message #130 received at 570377@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sun, Oct 11, 2015 at 10:07 PM, Vincent Lefevre <vincent@vinc17.net> wrote: > On 2015-10-11 21:36:19 +1300, Chris Tillman wrote: > > I bought a new (used) computer, and installed a new system. This annoying > > behaviour came back, of course, because I had set the old one up to get > rid > > of it. > > > > For anyone being affected by these bugs, or annoyed by removals being > > offered first, I'd suggest trying this in your ~/.aptitude/config file: > > > > Aptitude ""; > > Aptitude::ProblemResolver ""; > > Aptitude::ProblemResolver::Remove-Level "10001"; > [...] > > In https://lists.debian.org/debian-user/2014/07/msg00398.html > Andrei POPESCU suggested: > > Aptitude::ProblemResolver::SolutionCost "removals"; > > but this can lead to downgrades: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762932 > > How does your solution behave compared to this one? > > -- > 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) > Hi Vincent! You are over-represented in the list of potentially related bugs I compiled last night. I sense you are as frustrated as I am about this behaviour. For the simple example I gave, where my setting offered to upgrade rather than remove, with your setting substituted it did an "automatic fix" for broken packages. [image: Inline image 1] So the difference there was, it told me to fuggedabout it (my request). It also canceled that pending action. So I think the Remove-Level "10001" setting is probably more desirable based on that quick test ... because my stated intention was to upgrade (I pressed + on the binutils line).. Grepping the source shows that Remove-Level is a cfg_level, which is referred in quite a few places, potentially having complex effects: chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack Remove-Level src src/generic/apt/aptitude_resolver_universe.cc 878: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Remove-Level", ""), chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack parse_levels src src/generic/apt/aptitude_resolver_universe.h 1374: static cfg_level parse_levels(const std::string &level1, src/generic/apt/aptitude_resolver_universe.cc 847:cfg_level aptitude_universe::parse_levels(const std::string &level1, 864: parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Safe-Level", ""), 871: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Keep-All-Level", ""), 878: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Remove-Level", ""), 885: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Break-Hold-Level", ""), 892: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Non-Default-Level", ""), 899: return parse_levels(aptcfg->Find(PACKAGE "::ProblemResolver::Remove-Essential-Level", ""), chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack cfg_level srcsrc/generic/apt/aptitude_resolver_universe.h 1067:class cfg_level 1072: cfg_level(int _level, bool _is_discard) 1078: /** \brief Create a cfg_level that has no effect. */ 1079: cfg_level() 1084: static cfg_level make_level(int level) 1086: return cfg_level(level, false); 1089: static cfg_level make_conflict() 1091: return cfg_level(INT_MAX, true); 1097: bool operator<(const cfg_level &other) const 1108:std::ostream &operator<<(std::ostream &out, const cfg_level &level); 1366: static cfg_level parse_level(const std::string &s); 1374: static cfg_level parse_levels(const std::string &level1, 1376: cfg_level default_level); 1379: static cfg_level get_safe_level(); 1380: static cfg_level get_keep_all_level(); 1381: static cfg_level get_remove_level(); 1382: static cfg_level get_break_hold_level(); 1383: static cfg_level get_non_default_level(); 1384: static cfg_level get_remove_essential_level(); src/generic/apt/aptitude_resolver_universe.cc 813:std::ostream &operator<<(std::ostream &out, const cfg_level &level) 823:cfg_level aptitude_universe::parse_level(const std::string &s) 826: return cfg_level::make_level(cost_limits::maximum_level); 828: return cfg_level::make_level(cost_limits::minimum_level); 830: return cfg_level::make_conflict(); 840: return cfg_level::make_level(cost_limits::minimum_level); 843: return cfg_level::make_level(n); 847:cfg_level aptitude_universe::parse_levels(const std::string &level1, 849: cfg_level default_level) 858: return std::max<cfg_level>(parse_level(level1), parse_level(level2)); 861:cfg_level aptitude_universe::get_safe_level() 866: cfg_level::make_level(10000)); 869:cfg_level aptitude_universe::get_keep_all_level() 873: cfg_level::make_level(20000)); 876:cfg_level aptitude_universe::get_remove_level() 880: cfg_level::make_level(10000)); 883:cfg_level aptitude_universe::get_break_hold_level() 887: cfg_level::make_level(40000)); 890:cfg_level aptitude_universe::get_non_default_level() 894: cfg_level::make_level(50000)); 897:cfg_level aptitude_universe::get_remove_essential_level() 901: cfg_level::make_level(60000)); src/generic/apt/aptitude_resolver.cc 457: cfg_level safety_level; 702: cost apply_cfg_level(const cfg_level &level, 743: cfg_level keep_all_level(aptitude_universe::get_keep_all_level()); 744: cost keep_all_cost(apply_cfg_level(keep_all_level, cost_settings, safety_component)); 1173: cfg_level safe_level(aptitude_universe::get_safe_level()); 1174: cfg_level keep_all_level(aptitude_universe::get_keep_all_level()); 1175: cfg_level remove_level(aptitude_universe::get_remove_level()); 1176: cfg_level break_hold_level(aptitude_universe::get_break_hold_level()); 1177: cfg_level non_default_level(aptitude_universe::get_non_default_level()); 1178: cfg_level remove_essential_level(aptitude_universe::get_remove_essential_level()); 1433: apply_cfg_level(safe_level, cost_settings, safety_component) 1453: apply_cfg_level(remove_level, cost_settings, safety_component) 1485: apply_cfg_level(safe_level, cost_settings, safety_component)); 1505: apply_cfg_level(non_default_level, cost_settings, safety_component) 1529: apply_cfg_level(break_hold_level, cost_settings, safety_component) 1552: apply_cfg_level(remove_essential_level, cost_settings, safety_component)); ... But SolutionCost is more of a fine-tuning feature, which only influences the final decision: chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack SolutionCost src src/generic/apt/resolver_manager.cc 898: std::string cost_configuration = aptcfg->Find(PACKAGE "::ProblemResolver::SolutionCost", chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack cost_configuration src src/generic/apt/resolver_manager.cc 898: std::string cost_configuration = aptcfg->Find(PACKAGE "::ProblemResolver::SolutionCost", 904: cost_components = parse_cost_settings(cost_configuration); chris@ctillman:~/eiffel/projects/Eifflix/src/packages/aptitude/pre/aptitude-0.7.2$ ack cost_components src src/generic/apt/resolver_manager.cc 901: std::shared_ptr<std::vector<cost_component_structure> > cost_components; 904: cost_components = parse_cost_settings(cost_configuration); 916: cost_components = std::make_shared<std::vector<cost_component_structure> >(); 920: cost_components->push_back(cost_component_structure(cost_component_structure::combine_none, level0)); 924: cost_components->push_back(cost_component_structure(cost_component_structure::combine_none, level1)); 928: aptitude_resolver_cost_settings cost_settings(cost_components); -- Chris Tillman Developer
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]
"Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com>
to 600600-submit@bugs.debian.org.
(Thu, 12 Nov 2015 13:00:05 GMT) Full text and rfc822 format available."Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com>
to 600600-submit@bugs.debian.org.
(Thu, 12 Nov 2015 13:00:06 GMT) Full text and rfc822 format available.Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
to control@bugs.debian.org.
(Mon, 14 Mar 2016 22:51:04 GMT) Full text and rfc822 format available."Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com>
to control@bugs.debian.org.
(Sat, 19 Mar 2016 12:33:11 GMT) Full text and rfc822 format available.mafm@debian.org (Manuel A. Fernandez Montecelo):Vincent Lefevre <vincent@vinc17.net>:Message #143 received at 570377-close@bugs.debian.org (full text, mbox, reply):
Source: aptitude
Source-Version: 0.8-1
We believe that the bug you reported is fixed in the latest version of
aptitude, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 570377@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Manuel A. Fernandez Montecelo <mafm@debian.org> (supplier of updated aptitude package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Wed, 20 Apr 2016 16:35:17 +0100
Source: aptitude
Binary: aptitude aptitude-common aptitude-doc-cs aptitude-doc-en aptitude-doc-es aptitude-doc-fi aptitude-doc-fr aptitude-doc-it aptitude-doc-ja aptitude-doc-nl aptitude-doc-ru
Architecture: source all amd64
Version: 0.8-1
Distribution: unstable
Urgency: low
Maintainer: Aptitude Development Team <aptitude-devel@lists.alioth.debian.org>
Changed-By: Manuel A. Fernandez Montecelo <mafm@debian.org>
Description:
aptitude - terminal-based package manager
aptitude-common - architecture independent files for the aptitude package manager
aptitude-doc-cs - Czech manual for aptitude, a terminal-based package manager
aptitude-doc-en - English manual for aptitude, a terminal-based package manager
aptitude-doc-es - Spanish manual for aptitude, a terminal-based package manager
aptitude-doc-fi - Finnish manual for aptitude, a terminal-based package manager
aptitude-doc-fr - French manual for aptitude, a terminal-based package manager
aptitude-doc-it - Italian manual for aptitude, a terminal-based package manager
aptitude-doc-ja - Japanese manual for aptitude, a terminal-based package manager
aptitude-doc-nl - Dutch manual for aptitude, a terminal-based package manager
aptitude-doc-ru - Russian manual for aptitude, a terminal-based package manager
Closes: 157984 241945 246672 255587 266061 268698 328620 341963 357828 359171 365644 405506 415449 453935 548505 569315 570377 574132 588202 596221 610845 651410 651947 653284 661678 680334 686626 721426 722211 738350 743769 785641 798240 817065 817276 817547 817776 819002 819603 819636 820452
Changes:
aptitude (0.8-1) unstable; urgency=low
.
[ Manuel A. Fernandez Montecelo ]
* New upstream release. Please see /usr/share/aptitude/NEWS for a change
log with more details.
.
- New features:
* Detect and suggest solutions when pkgstates is corrupt (Closes: #405506)
* Allow to choose between localized logs or not (default is not) with the
option ::Localized-Log (Closes: #357828, #596221)
* [curses] Left/Right arrow keys collapse/expand one level of the subtree,
and when in a package item (row) Left jumps to "parent"
(Closes: #157984, #241945, #415449)
* [curses] Be able to Quit after dpkg run (Closes: #246672)
.
- Bug fixes:
* ~E pattern now returns packages with Essential only (Closes: #548505)
* Detect as "Security Upgrades" when site matches security.*.d.o
(Closes: #328620)
* Allow to run in dumb terminals when not requiring curses preview or
solution screen (Closes: #817276)
* "reinstall" planned action is now preserved across sessions, when
becoming root or in the command line with --schedule-only
(Closes: #255587, #785641)
* Fix crash when invoking curses resolver from command line
(Closes: #817776)
* Update internal state for upgrades without target version after the
action is performed (Closes: #721426)
* [curses] Fix for miscalculated Download Size field (Closes: #817547)
* Marking as keep, through ':' or other actions, clears Forbidden version
* Fix cases where user tags operations did not apply (Closes: #819002)
* Actions involving unfulfilled Recommends invoke the resolver
(Closes: #819636)
* Enhance infer_reason() to explain more cases of pkg_unused_remove
(Closes: #266061)
.
- User visible changes:
* [cmdline] Output in dumb terminals, when there is no piping/redirection
involved and even if ioctl doesn't work to get window size (e.g. inside
emacs), will now use COLUMNS instead of the default very big default
width
* Format string scapes for Source (%E->%e) and Architecture (%e->%E)
swapped (for consistency with search patterns, fix for #743769)
* New short form "~e" for search term "?source-package" (Closes: #743769)
* [curses] Remove option to run "dpkg-reconfigure" on a given package
(Closes: #680334, #686626, #738350)
* [cmdline] Solution screen for "Remove the following packages" shows
version and suite
.
- User visible changes (Resolver):
This subsection is to separate the (many) changes of the Resolver in this
version from other changes. Many more details in the "upstream" changelog
(NEWS).
.
Executive summary:
* Changes to the order in which solutions are offered in conflict
resolutions, so upgrades or keeps are preferred over removal of many
packages
(Closes: #341963, #359171, #365644, #453935, #569315, #570377, #574132,
#588202, #610845, #651410, #651947, #653284, #661678, #722211,
#798240)
.
A more detailed description of individual changes follows:
* Modify several resolver scores config variables
::ProblemResolver::RequiredScore = 8 (was: 4)
::ProblemResolver::ImportantScore = 4 (was: 5)
::ProblemResolver::StandardScore = 2 (was: 3)
::ProblemResolver::OptionalScore = 1
::ProblemResolver::ExtraScore = 0 (was: -1)
* Add new score for removal of obsolete package and corresponding config
variable ::ProblemResolver::RemoveObsoleteScore
Default to 310 to allow for easier upgrades and to counter the penalty
to remove packages (default -300).
* Add new score for partial solutions cancelling the removal of a package
and corresponding config variable ::ProblemResolver::CancelRemovalScore
Resolver actions cancelling the removal (or purge) of a package
requested to be removed/purged were not being penalised, now they are
(default -300).
* Only add Preserve{Auto,Manual}Score if the packages are actually
installed
Without this, the algorithm was assigning extra score +60 (default
PreserveManualScore) for packages which remained uninstalled
(were not to be installed) and when the user actually didn't select
them manually -- even if the justification was "because it is the
to-be-installed version of a manually installed package".
* Change the default score of several ::ProblemResolver config variables
* ::StepScore to -10 (was +70)
* ::PreserveManualScore to +20 (was +60)
* ::UpgradeScore to +30 (was 0)
* ::Keep-All-Level to 10000 (was 20000)
* Change how the costs are compared
* Apply InstallScore and UpgradeScore also when the packages are not
"manual"
.
- Internal changes:
* configure.ac: Allow to disable check for Boost library headers
individually
* Avoid extra code calling apt_load_cache() when already loaded
* [cmdline] Rejecting a solution advances to the next one only
* [General] Update FSF's postal address everywhere, drop duplicated
boilerplates
.
- Documentation:
* manpage:
* Minor clarification about "install" example (Closes: #268698)
.
- Translation updates:
* da.po: Danish translation by Morten Bo Johansen (Closes: #817065)
* ja.po: Japanese translation by Takuma Yamada (Closes: #819603)
* Actually enable Dutch (nl) documentation translation by Frans
Spiesschaert
.
.
* Add aptitude-doc-nl package
* d/control: Drop Build-dependencies present for a long time but which
haven't been used in the last few years:
- libboost-python-dev
- libboost-serialization-dev
.
[ Axel Beckert ]
* Demote Recommends on HTML documentation to Suggests. (Closes: #820452)
* Declare compliance with Debian Policy 3.9.8. (No changes needed.)
* Switch Homepage header from http:// to https://.
* Switch Vcs-Git header from git:// to https://.
* Convert debian/copyright to machine-readable DEP5 format and overhaul it.
* debian/rules: Use --dbgsym-migration instead of --ddeb-migration.
Checksums-Sha1:
88eb63c85a18f5257125f8541af924c24c94b6b4 2926 aptitude_0.8-1.dsc
0afcf52f45a49711c04c2a03e125f6b4879a79dd 4876972 aptitude_0.8.orig.tar.xz
c77e413cefa859a3af9bdc93b56df668eac1f77a 51544 aptitude_0.8-1.debian.tar.xz
299f647119e4a44975ad7fb65fc52522ce9799cc 1571944 aptitude-common_0.8-1_all.deb
179d406055319c0db66dfbaece45926dec886abf 20821620 aptitude-dbgsym_0.8-1_amd64.deb
83200b44518a407ec3b3e5d305449a8428aa2038 366332 aptitude-doc-cs_0.8-1_all.deb
f2a4d97610e8961a985b17fcc87824b8d00985be 433776 aptitude-doc-en_0.8-1_all.deb
a0adf0a650fe72c6a79aba97b4c0d5485d007ad3 412210 aptitude-doc-es_0.8-1_all.deb
b191f47dbed7b25dcf87425c79365ec1c8aeb867 273082 aptitude-doc-fi_0.8-1_all.deb
04e55ebf8925b2e531bade8777cb32c8e159d231 314568 aptitude-doc-fr_0.8-1_all.deb
b1d48131f60f2fdeed664ab9b5fd19c2e0c6ada6 275292 aptitude-doc-it_0.8-1_all.deb
8ff0bcc6c3d948b1e63ab0c6da732b9d3ed9f936 370288 aptitude-doc-ja_0.8-1_all.deb
b11dee57a8117a51cbb1648da41bb5a6c7120cec 374778 aptitude-doc-nl_0.8-1_all.deb
ac202e2e36ee7a69765f3ef4f8be1a7e22e828d5 390984 aptitude-doc-ru_0.8-1_all.deb
f1aac8e64f3a5f1ce8912ed78bb15e3b9b023971 1447480 aptitude_0.8-1_amd64.deb
Checksums-Sha256:
7c405c81e1850ae8d27719d4289a3aba4bee369e24692a856577a1eaccce8db6 2926 aptitude_0.8-1.dsc
dce79ff6b8869c021911cb695296eb98d1f3d7a7ed57b599bbcb43021a4c60a9 4876972 aptitude_0.8.orig.tar.xz
44b2c7acf588511ba6a129cc2836b7acd0f403ad48cf209383ab41427a0a99e9 51544 aptitude_0.8-1.debian.tar.xz
79ae72cf8e8d5ab87e729cf8ca8aa72e0fccb2524d43c7f17786f2ae4cf7e425 1571944 aptitude-common_0.8-1_all.deb
61db742434f3eab8af5f3841769f3dbd7eee5d34cb992c00af87f7a600a7ba61 20821620 aptitude-dbgsym_0.8-1_amd64.deb
6d65b622cec768ba91ad4f78762326793d316b9fbd95ffd71b894539903ea55a 366332 aptitude-doc-cs_0.8-1_all.deb
2ca12e51011dda960fb93e87921abb7c9c8edeadfa8424adae8b8166b4682f63 433776 aptitude-doc-en_0.8-1_all.deb
4296f46952e369d391de15627c69c0047d527993c935557ac9927afab16a5d35 412210 aptitude-doc-es_0.8-1_all.deb
9e65752806ac1c532dd8296efc92d968d1aea4bff2fdb994d5389c46ec6aa3a3 273082 aptitude-doc-fi_0.8-1_all.deb
edbe2fe4c8fb674998c025f35b36e119f18a47dd19ccda2a5bd39cf981cd28b3 314568 aptitude-doc-fr_0.8-1_all.deb
d0c60f3afddaeacf2099005a0d0e9b00d02fcfb0ddb7eaa316b65766c61b3f68 275292 aptitude-doc-it_0.8-1_all.deb
b2d46a606701eee5116f0cd4ad580293d57263f00a9b4804c61f657d8290424c 370288 aptitude-doc-ja_0.8-1_all.deb
33ba3e10f347e60a4ac6f7c1c139d0a1b19ed9e18349d228f520cbed65dc27f8 374778 aptitude-doc-nl_0.8-1_all.deb
5ae50bdf091044c761bbf05398f44c5f6a058ac248cf76cdb17342b02a9ed675 390984 aptitude-doc-ru_0.8-1_all.deb
750ff342199d033167d17bf99ae85c0309d9d0aa38d9df41d819609540043757 1447480 aptitude_0.8-1_amd64.deb
Files:
fbff5a49ff6e55a73cc331cfc193f5b1 2926 admin important aptitude_0.8-1.dsc
fd261cea000d6e818d9a81d6d4fe014d 4876972 admin important aptitude_0.8.orig.tar.xz
f31fa725d26ec22c44fb11a1461a1210 51544 admin important aptitude_0.8-1.debian.tar.xz
d81cbc91f7ee2124ae79213806ab8e9d 1571944 admin important aptitude-common_0.8-1_all.deb
0e2c2e077e2002898ec51bc9613c2f65 20821620 debug extra aptitude-dbgsym_0.8-1_amd64.deb
99a4d3c23abb00a5a905b799f7c30e54 366332 doc optional aptitude-doc-cs_0.8-1_all.deb
34f6d5ec70586b34bcc7ce8cd2841ba4 433776 doc optional aptitude-doc-en_0.8-1_all.deb
eaeae8a7775325a612d48d557d5096ee 412210 doc optional aptitude-doc-es_0.8-1_all.deb
436556de52322b8399ad298f33a2c40f 273082 doc optional aptitude-doc-fi_0.8-1_all.deb
dccd8c5240ad760b6769cdc69161adf3 314568 doc optional aptitude-doc-fr_0.8-1_all.deb
4a2425279f19b7e0125217c26fa04b26 275292 doc optional aptitude-doc-it_0.8-1_all.deb
b271454176b3eaf2ffa06ee3c89140e8 370288 doc optional aptitude-doc-ja_0.8-1_all.deb
eeda8ca136f806bce51ba87c6d599e4b 374778 doc optional aptitude-doc-nl_0.8-1_all.deb
5fdf94276ee6499bd52afb3c143edd2a 390984 doc optional aptitude-doc-ru_0.8-1_all.deb
2e1e0ef68169118fe7c73c687487d14c 1447480 admin important aptitude_0.8-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJXF6LAAAoJEH92BqRF3KgOIY4P/3NdRNmITtas1ixYc6+Ta2K/
O1DqjZy6+2pBmjKKIgi2IQdSwdnOfsLqHEE5279TVZRv6lVX5E5EdUC72fW+eqXr
s3mHg341pqVgVchhOBC7jF0hPHOEN+jCvDr4/etehPobBsXy2o0HKXEy+FNO2ZW7
9+IiA3SmYoTm0k3FNiynet4/S9NX0L9C2ToOcF6Q3fYZowKoORQZ5olj0aNVZz+L
i/0tpl49kymlMXiEzWBn5T8n5XJeaDZF1CO9MRXLpf/4r/3Alnj+k6dEHv0TuUwd
xRJSekgxQXNdCgi9d078wDsTAKhBDsKZne14U4vXPjsESABiU9VIArKP5oRSinXc
LB88sRUWt+O9h//sGL8CrI8SRgiCnwn3Ia6xyKIs7VafXKxzwl7iWq4nwuAIGWer
SmEN8UFBrnj4bOni8s45t4+oUEK8bo8x8p9vTxvPwjYYimtLEBp5I/TL83Uuvsve
nu4037eiHmZJKITWBv6NK8PwY9Xssy5iJdyt4wsFKxtwh01Kvfu62yjjLA9GVqmZ
pbCik8gxlcny9+YvEjGrL9bHYrixoXnf8OTeuAhA2sV0aVZV2AFUoXCCsGHBJ7Vk
5I7jXS0d8+z4e3cMB8c7Pyy35pUNBWGl6kMetU6b+9pdG1Olebn9jF6hO552eKA9
SAJbvGQMTCeA1zDz0BeS
=aRes
-----END PGP SIGNATURE-----
mafm@debian.org (Manuel A. Fernandez Montecelo):Stuart Prescott <stuart+debian@nanonanonano.net>:Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Sun, 14 Aug 2016 07:25:00 GMT) Full text and rfc822 format available.Send a report that this bug log contains spam.
Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.