[Aptitude-devel] Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix


Hi,

2015-09-21 12:43 Manuel A. Fernandez Montecelo:
>
>If I ask aptitude to upgrade a package and the dependencies cannot be
>fulfilled (as explained above for unstable), it is natural that aptitude
>tries to come up with weird solutions.  That includes downgrading.  So
>if I want to upgrade the version of 10 packages in unstable, and they
>depend on the new libstdc++6, and there is one dependency from
>experimental (libmad1.1) which had been compiled against the old
>libstdc++6 while there is "libmad1.0" in unstable compiled against the
>new libstdc++6, is is natural and reasonable that aptitude offers me a
>downgrade -- it is the easiest way to satisfy upgrading 10 packages and
>just downgrading one, without removals or other also negative effects.
>
>I am the master juggling blades, I am using unstable and experimental, I
>tweak the resolver parameters to my heart's content, I ask to upgrade
>things in the middle of a terribly complicated transition, and aptitude
>does not treat me like as an idiot: it *offers* me a *possible solution*
>to the conflicting states after an action that I *requested*, that
>includes downgrades.  It didn't break my system just casually like
>sitting there on the filesystem, or while doing "aptitude update", or
>when reinstalling a package, or upgrading from one stable to the next.
>
>I don't see anything wrong with that, that is part of the core function
>of aptitude, to put me in charge.  In fact, I would be disappointed if
>aptitude didn't offer me slightly awkward solutions that would fit the
>bill sometimes.
>
>[...]
>
>According to the documentation, "removal" means: "Counts the number of
>packages that the solution removes".
>
>I assume that this works as intended and doesn't like solutions like
>removing obsolete libraries (of which there are lots lately, specially
>after the *v5 mass-renaming for example and with gcc-5 adding lots of
>"breaks" to some packages), so maybe it doesn't have better options (in
>terms of "resolver costs") than to downgrade.


So after studying this for a while, this is normal behaviour when using
"removals", which only pays attention to minimise the number of
removals, no matter any other considerations like upgrades, downgrades,
or prefering packages with higher priorities.

Using the default ("safety, priority") puts dangerous actions like
downgrades or changing to other non-default versions in a different
"safety" level, so they are not offered as the first solutions.

"safety, removals" can probably be used to avoid having downgrades while
minimising removals.


Even in this case, the fact that it was offering downgrades instead of
upgrades at the time when this was reported was because of the chaos
caused by the GCC-5/C++11 transition (the worst in a decade).

So only when the combination of all these unlikely cases happen
simultaneously, downgrades are offered.  Downgrades are highlighted and
have to be confirmed explicitly by the sysadmin.

It's working as documented and not a bug.


>By default it probably does, because I can't remember if I was ever
>offered a downgrade.  Again, you were using non-default options.
>
>Note also about full-upgrade:
>
>       full-upgrade
>
>           Upgrades installed packages to their most recent version, removing
>           or installing packages as necessary. This command is less
>           conservative than safe-upgrade and thus more likely to perform
>           unwanted actions. However, it is capable of upgrading packages
>           that safe-upgrade cannot upgrade.
>
>So, in short, if you don't want surprises, probably you should use
>"safe-upgrade" and not "full-upgrade -y".
>
>[...]
>> No, the best solution is to require the user to solve the problem
>> manually.
>
>Well, it idoes, it offered you a solution, as far as I am aware, for
>you to decide.  Only when passing "-y" it didn't, and rightly so.

Ditto.



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