[Aptitude-devel] Bug#691955: aptitude: Aptitude::ProblemResolver::SolutionCost does not support substraction

Daniel Hartwig mandyke at gmail.com
Thu Nov 1 03:28:52 UTC 2012


On 1 November 2012 00:59, Axel Beckert <abe at debian.org> wrote:
> I tried to weight removals-of-manual higher than other removals and came
> up with the following rule:
>
> aptitude -o Aptitude::ProblemResolver::SolutionCost='10 * removals - 9 * removals-of-manual + canceled-actions' remove htop

This cost formula prefers removing manual packages.  Assuming that
subtraction worked, it finds solutions in this order:

1) remove one manual (10*1 - 9*1 = 1)
2) remove one manual, two auto (10*3 - 9*1 = 21)
3) remove two manual, two auto (10*4 - 9*2 = 22)
4) remove three auto (10*3 - 9*0 = 30)
5) remove one manual, three auto (10*4 - 9*1 = 31)
6) remove four auto (10*4 - 9*0 = 40)

where as “removals + 3 * removals-of-manual” gives:

1) remove three auto (3 + 3*0 = 3)
2) remove one manual (1 + 3*1 = 4)
2) remove four auto (4 + 3*0 = 4)
4) remove one manual, two auto (3 + 3*1 = 6)
5) remove one manual, three auto (4 + 3*1 = 7)
6) remove two manual, two auto (4 + 3*2 = 10)

which prefers removing automatic packages over manual at a ratio of
about 3:1.  I presume you were trying to achieve something similar to
the second list.

There are also other options, such as a adjusting the scales of the
later example, a SolutionCost of “removals-of-manual, …”, or adding
“reject !~M :UNINST” to Hints.

> A simpler, yet less practical SolutionCost value with which we were able
> to reproduce the issue is:
>
> aptitude -o Aptitude::ProblemResolver::SolutionCost='removals - canceled-actions' remove htop

Indeed that is very impractical!  The resolver will find that removing
two packages and cancelling all requested actions if preferable to
just removing those two packages.

* On subtraction in SolutionCost

Simpler solutions (those with less actions) are often more preferable.
 This fits well with using only scaled addition, where extra actions
increase the cost of a solution by some amount.  The costs of actions
can be adjusted relative to each other (“prefer this amount of install
over that amount of remove”).  With subtraction, it becomes possible
to prefer increasing amounts of some action over anything else.

Consider a cost formula containing “- installs” which would prefer to
install a package A and hundreds of others, over simply installing A.
Where do those hundreds of other packages come from and what are they
related to?  Various odd places (the resolver investigates some
strange things on it's way to sanity land), and we have all seen such
solutions offered later.  With subtraction these excessive solutions
will be moved right to the front—the more installs the better, and
damn anything else.

Generally, using subtraction in SolutionCost will lead to strange results.

I would be very interested to find a practical example of subtraction
that is better than a similar formula using addition.  Supporting
subtraction is trivial, but lets avoid this unless there are real
benefits to doing so.

Regards



More information about the Aptitude-devel mailing list