On Tue, 29 Sep 2015, Manuel A. Fernandez Montecelo wrote:
[...]
> I am afraid that unstable and testing at the moment might still not be
> ready to upgrade fully, specially if you have KDE packages installed and
> you don't want to loose some of them.
Yes, that's exactly my predicament. I had already marked all packages
for upgrade but I finally got through it by using 'b' (find broken
packages) + ':' (hold temporarily) + recursing through the exact version
of the package being installed to hold its broken dependencies. Required
multiple passes. Took hours to get through it all though.
While I was at it I marked a bunch of packages as automatically
installed ('M').
But the point remains: the dependency resolution should not rnu out of
memory like that. My system was not in a broken state so it's also
surprising it's unable to find the obvious solution which is to not
upgrade anything.
Even if it's unable to find a solution it should be able to at least
show the conflicts.
For bonus points it should also present independant conflicts
separately. For instance currently I have a problem with a package that
depends on the mysql-client virtual package which is not provided by the
new mysql-client-5.6 package. Chances are this is totally independent
from the libstdc++6 conflicts. But the conflict resolution dialog
systematically shows all conflicts together, making figuring things out
much harder for the administrator, and also causes a combinatorial
explosion in the number of possible solutions.
This also leads me to wonder whether partitionning independent conflicts
could help find solutions using less CPU and memory (though here the
libstdc++6 issue alone seems to be enough to cause memory usage to
explode).
--
Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/
In a world without fences who needs Gates?
