[Aptitude-devel] Bug#795228: aptitude: upgraded a package to experimental without notice

[Manuel A. Fernandez Montecelo]

2016-03-17 02:43 Vincent Lefevre:
>Hi,
>
>On 2016-03-17 00:10:55 +0000, Manuel A. Fernandez Montecelo wrote:
>> With the SolutionCost of "removals", aptitude doesn't take into account
>> installing by priorities or non-default releases, it just tries to
>> minimise the removals, so seing that it could solve the problem by
>> upgrading to 2.7-1~exp1, it just did that.
>
>IMHO, that's bad.

Other people beg to differ, e.g. #608811 and #658635.

I am generally of the same opinion as you, and so is aptitude with the
default rules, so the suggestions of upgrading packages to experimental
or other non-default releases is offerend only last.


>FYI, I chose the "removals" SolutionCost to avoid
>breaking the system due to removed packages. But installing
>experimental packages is not a good solution as such packages may
>break the system. There should be a way to block upgrades as long as
>they are not safe (no removals of manually installed packages[*], no
>experimental packages).
>
>[*] except when the feature is provided by another package (such as
>with renamed packages).

"removals" just tries to minimise the number of removals, without having
other things into account like "don't upgrade to packages in
experimental".

Looking at the documentation, maybe you should use "safety, removals",
"priority, removals" or "non-default-actions*1000 + removals".

Probably none of these combinations are tested, and things are quite
difficult with the resolver as they are, so no promises that it will
work better or that it will not produce unexpected/undesired results
sometimes, though.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>