[Aptitude-devel] Bug#658635: Resolver extremely reluctant to upgrade packages to experimental, even as dependencies of packages in experimental

[Josh Triplett]

On Sat, Jun 11, 2016 at 01:03:39PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2012-02-04 19:10 Josh Triplett:
> > Package: aptitude
> > Version: 0.6.4-1.2
> > Severity: normal
> > 
> > I've run into similar problems before, but this time I had something I
> > could easily reproduce and provide a transcript for.  Also, I've run
> > into similar problems that don't involve experimental at all, but in
> > this case the involvement of experimental seems like the likely culprit.
> > 
> > I tried to upgrade iceweasel from 10 in unstable to 11 in experimental.
> > Doing so requires installing xulrunner-11.0 and libmozjs11d from
> > experimental, and upgrading libnss3-1d to experimental.  aptitude's
> > resolver seems extremely reluctant to do the latter.  I'll provide two
> > transcripts below, one where I don't provide the resolver with any
> > accept/reject hints (and it takes quite a few steps to do something
> > sensible), and one where I explicitly reject things I don't want it to
> > do (and it still needs two rejections before reaching the correct
> > solution).  In any case, the resolver should have gone immediately to
> > the solution I ended up with, and shouldn't have presented the situation
> > as brokenness that needed fixing in the first place.
> 
> I disagree.  Giving hints is an integral part of using aptitude and its
> resolver.

That much I agree with; I think it's normal, in situations where there's
actually breakage in the archive, to have to give hints to determine
which of various suboptimal solutions to use.  For instance, if someone
accidentally builds a package in unstable against libraries from
experimental, and I ask aptitude to install that package in unstable,
I'd fully expect to need hints to get to "switch the libraries from
unstable to experimental".

I'm *not* arguing that every single case where I have to give aptitude
hints or accept/reject iterations is a bug.  I'm arguing that this
*specific* case, of explicitly upgrading a package to a version only
available in a non-default distribution, should have an additional
heuristic to make aptitude consider it more reasonable to upgrade other
packages to that same non-default distribution.

> Otherwise, aptitude will rightly try to install things from the default
> versions, which presumably are not experimental, e.g. stable or unstable.
> 
> For example, if one uses mostly stable and has testing for the
> occasional package, one doesn't want that by asking to upgrade
> ${desktop-app} which depends on ${network-manager} which depends on
> ${initd}, one ends up pulling half of testing without enough warning.
> People are really upset about that some times, judging by the tone of
> the bug reports.

When installing a package from testing, I'd fully expect such
installation to pull in more packages from testing.  I don't see why
that consitutes "without enough warning"; aptitude gives a great preview
screen showing all the actions it will take, and if the installation of
one package produces a preview that has screenfuls of upgrades, that
should make it clear what happened and give an opportunity to consider
before proceeding.

> (The fact that it suggested "remove" as a first action was a well-known
> problems present for many years, independently of this particular case).
> 
> Other than that, aptitude's resolver is a complex beast which works
> based on heuristics.  The way to guide those heuristics is to give
> user-desired hints.  It will suggest to Keep few packages installed
> rather than upgrade many, specially if they come from non-default
> versions.

I don't think it suffices to just wave off sub-optimal results from the
resolver with "the resolver is subtle and quick to anger, and your
packages are crunchy and taste good with ketchup".  Yes, the resolver
won't be perfect every time, but it could potentially be improved.

- Josh Triplett