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

Vincent Lefevre vincent at vinc17.net
Tue May 17 02:15:20 UTC 2016


Hi,

On 2016-05-14 10:53:03 +0100, Manuel A. Fernandez Montecelo wrote:
> 2016-05-10 15:14 Vincent Lefevre:
> > 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".

Well, the actual issue here is that I usually use the UI, which
behaves like with --full-resolver.

> 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.

But note that I use SolutionCost "safety, removals", so that it should
avoid packages from experimental or remove packages.

> 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.

This is not specific to multi-arch. This can also happen with usual
dependencies. But since I use SolutionCost "safety, removals", I
prefer to block the upgrade of the problematic packages.

> 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"?

No, the next solutions were worse, i.e. more packages would have been
removed.

Note also that before I reported the bug, there were more packages
proposed for upgrade, but because any solution wanted to remove
packages, I had to select the upgradable packages (those with no
conflicts) one by one to upgrade them. Very annoying!

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



More information about the Aptitude-devel mailing list