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

[Daniel Hartwig]

On 4 February 2014 10:24, Vincent Lefevre <vincent at 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.