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.montez...@gmail.com>
