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

[Daniel Hartwig]

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