Bug#341963: aptitude: Too low penalty for not honoring user request
On Tue, Dec 06, 2005 at 07:47:57PM +0100, Mikael Nilsson <[EMAIL PROTECTED]> was heard to say: > tis 2005-12-06 klockan 10:12 -0800 skrev Daniel Burrows: > > not terribly interested in adding more ways to throw away solutions > > entirely, > > as the more complicated you make those schemes, the more likely that they'll > > eliminate solutions that are actually good. For instance, saying "never > > remove packages that are to be upgraded" fails when you're upgrading two > > packages A and B, where the newer version of A conflicts with B. > > I fully understand that. However, I see no reason why solutions that > contradict your orders should ever come *before* options that obey your > orders. I would very much like to know what the potential negative > consequences of a (very) high default value for that option might be? > I'll definitely try it out and report back. Especially now that the > complex C++ allocator transition is ongoing, I have these situations > quite often... The main reason this isn't implemented is that I haven't had the time to analyze it and figure out a good solution. It might be as simple as tweaking the score of each non-automatic non-kept package, but I'd want to think about that and run some tests before making the change. On Tue, Dec 06, 2005 at 08:36:51PM +0100, Mikael Nilsson <[EMAIL PROTECTED]> was heard to say: > tis 2005-12-06 klockan 10:47 -0800 skrev Daniel Burrows: > > The option is actually Aptitude::ProblemResolver::PreserveManualScore; > > no hyphen. This is contrary to the documentation, which I've now fixed. > > The reason that this is not a very strong imperative is that it forces > > the program to try *very hard* to preserve the states of manual packages. > > This in turn means that it can be difficult to find any solution at all > > (indeed, I was able to quickly guide the search to a solution without > > setting this; with this option, it ran out of solutions almost right away). > > That's certainly a negative side effect... I wasn't expecting that - I > was expecting more or less a reordering of solutions. Oh well, I guess > it can be hard to predict such algorithms. The thing is that scoring is used to decide where to search. If every action makes things worse, you end up looking at the whole search space before finding a solution. Daniel signature.asc Description: Digital signature
Bug#341963: aptitude: Too low penalty for not honoring user request
tis 2005-12-06 klockan 10:47 -0800 skrev Daniel Burrows: > The option is actually Aptitude::ProblemResolver::PreserveManualScore; > no hyphen. This is contrary to the documentation, which I've now fixed. > The reason that this is not a very strong imperative is that it forces > the program to try *very hard* to preserve the states of manual packages. > This in turn means that it can be difficult to find any solution at all > (indeed, I was able to quickly guide the search to a solution without > setting this; with this option, it ran out of solutions almost right away). That's certainly a negative side effect... I wasn't expecting that - I was expecting more or less a reordering of solutions. Oh well, I guess it can be hard to predict such algorithms. Anyway, I do think that stability (= actually finding reasonable solutions, even though the desired one is not always the first found) is to prefer over 100% predictability (which is what I wanted :-). > > You could instead set Aptitude::CmdLine::Request-Strictness to a large > value. This just tries to preserve the states of packages listed on the > command-line. It isn't set by default because I feel that the command-line > and the visual interface should have identical behavior. Even this wasn't > enough to make your preferred option come up first, although it was the > third solution I got. Seems like something for me to try then. Thanks for the analysis! /Mikael > > Daniel -- Plus ça change, plus c'est la même chose
Bug#341963: aptitude: Too low penalty for not honoring user request
The option is actually Aptitude::ProblemResolver::PreserveManualScore; no hyphen. This is contrary to the documentation, which I've now fixed. The reason that this is not a very strong imperative is that it forces the program to try *very hard* to preserve the states of manual packages. This in turn means that it can be difficult to find any solution at all (indeed, I was able to quickly guide the search to a solution without setting this; with this option, it ran out of solutions almost right away). You could instead set Aptitude::CmdLine::Request-Strictness to a large value. This just tries to preserve the states of packages listed on the command-line. It isn't set by default because I feel that the command-line and the visual interface should have identical behavior. Even this wasn't enough to make your preferred option come up first, although it was the third solution I got. Daniel signature.asc Description: Digital signature
Bug#341963: aptitude: Too low penalty for not honoring user request
tis 2005-12-06 klockan 10:12 -0800 skrev Daniel Burrows: > > Is there an apt.conf option that increases the penalty for those options? > > Maybe the default value of that penalty should be considerably increased. > > The option in question is Aptitude::ProblemResolver::PreserveManualScore; > I would be interested in hearing whether you have any trouble with that > cranked up to 1000 or so over a period of time. (the default is 60) I'm Actually, I found it after I sent this report. Unfortunately, it did *nothing* the change the situation. I set it to 2, I set it to -1, and nothing changed. Ehhh, now looking again at file:///usr/share/doc/aptitude/html/en/ch02s04s05.html I see: Option: Aptitude::Problem-Resolver::PreserveManualScore which is what I used. Well, it seems that should be ProblemResolver (without the '-')... Thus, I need to try that again :-) Should I file a doc bug? > not terribly interested in adding more ways to throw away solutions entirely, > as the more complicated you make those schemes, the more likely that they'll > eliminate solutions that are actually good. For instance, saying "never > remove packages that are to be upgraded" fails when you're upgrading two > packages A and B, where the newer version of A conflicts with B. I fully understand that. However, I see no reason why solutions that contradict your orders should ever come *before* options that obey your orders. I would very much like to know what the potential negative consequences of a (very) high default value for that option might be? I'll definitely try it out and report back. Especially now that the complex C++ allocator transition is ongoing, I have these situations quite often... /Mikael -- Plus ça change, plus c'est la même chose
Bug#341963: aptitude: Too low penalty for not honoring user request
On Sun, Dec 04, 2005 at 02:26:54PM +0100, Mikael Nilsson <[EMAIL PROTECTED]> was heard to say: > Package: aptitude > Version: 0.4.0-3 > Severity: normal > > > I'm generally quite happy with the new problem resolver in aptitude, but in > a few cases I find it less that useful. > > Case in point: I was trying to install evolution from experimental. aptitude > is your friend here, because this is a complex transition involving dbus and > a lot of gnome stuff. > > I did: > > aptitude -t experimental install evolution > > which I assumed would do the job for me. However, the first 20 or so > alternatives that it presented as a problem resolution involved either > removing evolution altogether, or not upgrading it. It was only after a > looong series of "no, no, no..." that it found a working solution. See > below. > > I find it a bit strange that it didn't find this earlier. After all, I asked > for an upgrade of evolution, so that should be priority #1. Removing it > should probably *never* be an option, nor keeping it. Or at least a last > resort... The first alternative to show should be "what happens if you > *really* want to do this?". Only when that turns out not to be possibly > should you consider the other options. > > Is there an apt.conf option that increases the penalty for those options? > Maybe the default value of that penalty should be considerably increased. The option in question is Aptitude::ProblemResolver::PreserveManualScore; I would be interested in hearing whether you have any trouble with that cranked up to 1000 or so over a period of time. (the default is 60) I'm not terribly interested in adding more ways to throw away solutions entirely, as the more complicated you make those schemes, the more likely that they'll eliminate solutions that are actually good. For instance, saying "never remove packages that are to be upgraded" fails when you're upgrading two packages A and B, where the newer version of A conflicts with B. Daniel signature.asc Description: Digital signature
Bug#341963: aptitude: Too low penalty for not honoring user request
Package: aptitude Version: 0.4.0-3 Severity: normal I'm generally quite happy with the new problem resolver in aptitude, but in a few cases I find it less that useful. Case in point: I was trying to install evolution from experimental. aptitude is your friend here, because this is a complex transition involving dbus and a lot of gnome stuff. I did: aptitude -t experimental install evolution which I assumed would do the job for me. However, the first 20 or so alternatives that it presented as a problem resolution involved either removing evolution altogether, or not upgrading it. It was only after a looong series of "no, no, no..." that it found a working solution. See below. I find it a bit strange that it didn't find this earlier. After all, I asked for an upgrade of evolution, so that should be priority #1. Removing it should probably *never* be an option, nor keeping it. Or at least a last resort... The first alternative to show should be "what happens if you *really* want to do this?". Only when that turns out not to be possibly should you consider the other options. Is there an apt.conf option that increases the penalty for those options? Maybe the default value of that penalty should be considerably increased. /Mikael Solution that works for me: Remove the following packages: dbus-1 dbus-glib-1 libebook1.2-3 libedataserverui1.2-4 libhal-storage0 libhal0 libnautilus-burn1 Install the following packages: dbus [0.50-3 (experimental, now)] libdbus-1-1 [0.50-3 (experimental, now)] libdbus-glib-1-1 [0.50-3 (experimental, now)] libgdl-1-0 [0.6.0-1 (experimental, now)] libgdl-1-common [0.6.0-1 (experimental)] libhal-storage1 [0.5.5.1-1 (experimental, now)] libhal1 [0.5.5.1-1 (experimental, now)] libnautilus-burn2 [2.12.1-2 (experimental, now)] libwnck18 [2.12.1-1 (experimental, now)] libxres1 [6.8.2.dfsg.1-10 (unstable)] Upgrade the following packages: dbus-1-utils [0.23.4-7 (unstable, now) -> 0.50-3 (experimental)] evolution-data-server [1.2.3-8 (unstable, now) -> 1.4.1.1-1 (experimental)] evolution-plugins [2.2.3-5 (unstable, now) -> 2.4.1-3 (experimental)] gconf2 [2.10.1-6 (unstable, now) -> 2.12.1-4 (experimental)] gconf2-common [2.10.1-6 (unstable, now) -> 2.12.1-4 (experimental)] gnome-media [2.10.2-1 (unstable, now) -> 2.12.0-1 (experimental)] gnome-volume-manager [1.2.1-1 (unstable, now) -> 1.4.0-1 (experimental)] gnomemeeting [1.2.2-1 (unstable, now) -> 1.2.2-1experimental1 (experimental)] hal [0.4.8-8 (unstable, now) -> 0.5.5.1-1 (experimental)] libedata-book1.2-2 [1.2.3-8 (unstable, now) -> 1.4.1.1-1 (experimental)] libedata-cal1.2-1 [1.2.3-8 (unstable, now) -> 1.4.1.1-1 (experimental)] libedataserver1.2-4 [1.2.3-8 (unstable, now) -> 1.4.1.1-1 (experimental)] libeel2-2 [2.10.1-3 (unstable, now) -> 2.12.1-1 (experimental)] libeel2-data [2.10.1-3 (unstable, now) -> 2.12.1-1 (experimental)] libeel2-dev [2.10.1-3 (unstable, now) -> 2.12.1-1 (experimental)] libgconf2-4 [2.10.1-6 (unstable, now) -> 2.12.1-4 (experimental)] libgconf2-dev [2.10.1-6 (unstable, now) -> 2.12.1-4 (experimental)] libgnomevfs2-0 [2.10.1-5 (unstable, now) -> 2.12.1.1-1 (experimental)] libgnomevfs2-common [2.10.1-5 (unstable, now) -> 2.12.1.1-1 (experimental)] libgnomevfs2-dev [2.10.1-5 (unstable, now) -> 2.12.1.1-1 (experimental)] nautilus-cd-burner [2.10.2-2 (unstable, now) -> 2.12.1-2 (experimental)] pmount [0.8-2 (unstable, now) -> 0.9.6-1 (experimental)] python2.3-gnome2-extras [2.10.2-1 (unstable, now) -> 2.12.1-1 (experimental)] sound-juicer [2.10.1-3 (unstable, now) -> 2.12.2-1 (experimental)] Score is -2197 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.42.3 Advanced front-end for dpkg ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2 2.0.16-1 type-safe Signal Framework for C++ ii libstdc++64.0.2-5The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.0-5English manual for aptitude, a ter -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
