[Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading

[Chris Tillman]

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 at gmail.com> wrote:

> On 6 February 2014 06:37, Vincent Lefevre <vincent at vinc17.net> wrote:
> > On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote:
> >> On 4 February 2014 19:53, Vincent Lefevre <vincent at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20140208/6d3b905e/attachment.html>