[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2016-05-10 15:14 Vincent Lefevre:
>Package: aptitude
>Version: 0.8.1-1
>Severity: normal
>
>I have:
>
>Aptitude::ProblemResolver::SolutionCost "safety, removals";
>
>cventin:~> aptitude upgrade -s
>Resolving dependencies...
>Unable to resolve dependencies for the upgrade: no solution found.
>Unable to safely resolve dependencies, try running with --full-resolver.

So, as far as I can see, aptitude is correctly assessing that it's
unable to "safely resolve dependencies" if upgrading.

It suggest to run with --full-resolver in the case that one wants to
upgrade "non-safely".  This is not the case, but it might happen that it
could upgrade by removing some packages (which maybe are not interesting
for the user or forgot that they were installed), or upgrading some
packages to a suite like experimental (which is a "non-default/safety
action", but which some people request from time to time, e.g. #608811),
or that one doesn't really want to use these multi-arch packages
anymore.

So it tries harder with --full-resolver.


>No problems here. But with --full-resolver:
>
>cventin:~> aptitude upgrade -s --full-resolver
>The following packages will be upgraded:
>  libegl1-mesa libegl1-mesa-dev libgbm1 libgl1-mesa-dev libgl1-mesa-dri
>  libgl1-mesa-glx{b} libglapi-mesa{b} libgles1-mesa libgles2-mesa
>  libwayland-egl1-mesa libxatracker2 mesa-common-dev mesa-vdpau-drivers
>13 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>Need to get 7902 kB of archives. After unpacking 4984 kB will be used.
>The following packages have unmet dependencies:
> libglapi-mesa : Breaks: libglapi-mesa:i386 (!= 11.2.1-2) but 11.1.3-1 is installed
> libglapi-mesa:i386 : Breaks: libglapi-mesa (!= 11.1.3-1) but 11.2.1-2 is to be installed
> libgl1-mesa-glx : Breaks: libgl1-mesa-glx:i386 (!= 11.2.1-2) but 11.1.3-1 is installed
> libgl1-mesa-glx:i386 : Breaks: libgl1-mesa-glx (!= 11.1.3-1) but 11.2.1-2 is to be installed

This is always going to happen when using several architectures with
suites like unstable or experimental at the same time (I don't think
that it happens in stable, and hopefully it doesn't happen in testing),
because packages in different architectures are not guaranteed to be
there at the same time.  The situation usually resolves itself in the
next few hours, when all packages are available.  But not always,
e.g. they might fail to compile for some reason and not be available for
a long time

So the upgrade cannot happen until all packages are at the same exact
version, including binNMUs, without removing some of them.


>The following actions will resolve these dependencies:
>
>      Remove the following packages:
>1)      libgl1-mesa-glx:i386 [11.1.3-1 (now, testing, unstable)]
>2)      libglu1-mesa:i386 [9.0.0-2.1 (now, testing, unstable)]
>3)      libwine:i386 [1.8.1-2 (now, testing, unstable)]
>4)      wine32:i386 [1.8.1-2 (now, testing, unstable)]
>
>      Keep the following packages at their current version:
>5)      libgl1-mesa-dev [11.1.3-1 (now, testing)]
>6)      libgl1-mesa-glx [11.1.3-1 (now, testing)]
>7)      libglapi-mesa [11.1.3-1 (now, testing)]
>8)      libgles1-mesa [11.1.3-1 (now, testing)]
>9)      libgles2-mesa [11.1.3-1 (now, testing)]
>10)     mesa-common-dev [11.1.3-1 (now, testing)]
>
>      Leave the following dependencies unresolved:
>11)     wine64 recommends wine32 (>= 1.8.1-2)
>12)     wine64 recommends wine32 (< 1.8.1-2.1~)

Consistent with the conflicts above.


2016-05-10 15:29 Vincent Lefevre:
>In the UI, I get the same behavior as with --full-resolver:
>aptitude wants to remove packages. And in both cases, if I
>look at the next solutions, aptitude wants to remove more
>and more packages.

I hope that one of the solutions offered is to "Keep all at the current
version"?

(At least if the packages are not already in an inconsistent state, by
being forced before into installing conflicting versions).


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