[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 06:57:14PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2016-06-11 18:14 GMT+01:00 Josh Triplett <josh at joshtriplett.org>:
> > 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.
> 
> aptitude is just applying pin priorities as apt ecosystem provides.
> The way to tell aptitude (and apt tools in general) that one wants to
> temporarily pin "experimental" (or others) higher is to specify the
> Default-Release (or --target-release option in aptitude).
> 
> The mechanism is there, it's just not automatically applied just by
> asking to upgrade, and I don't think that it should be changed at this
> point.

I don't think that installing a package version from experimental should
change the target release; I'm just suggesting that it affect the
heuristic weights for things like "should I upgrade a package to a
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.
> 
> I'd tend to agree that aptitude (esp. in the curses UI) gives enough
> warning, but you'd be amazed to see that even with the current
> behaviour some people complain a lot about aptitude taking packages
> from non-default releases "lightly".
> 
> In the command-line execution, the view is something like this:
> 
>   =========================
>   The following packages will be upgraded:
>     libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core
>     libreoffice-draw libreoffice-impress libreoffice-kde libreoffice-math
>     libreoffice-style-breeze libreoffice-style-galaxy libreoffice-style-oxygen
>     libreoffice-style-tango libreoffice-writer python3-uno uno-libs3 ure
>   =========================
> 
> If the resolver is not invoked, versions are not shown by default, so
> users cannot see if they are upgrading to versions of experimental
> until the download+installation takes place.

That seems potentially fixable.  What about "The following packages will
be upgraded to experimental:", in a separate heading?  (Likewise for any
packages upgraded to a non-default distribution.)

Or, alternatively, add the "/experimental" suffixes, but that seems
noisier; a separate heading reduces the noise.

> >> (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.
> 
> That aptitude's resolver is quick to anger is one way to view it.

It was a joke, not an assessment.  The resolver is awesome and helpful,
just not perfect.

> I've been improving the resolver lately in other ways, I just don't
> see this as a useful improvement, sorry.

Sad to hear that; this remains one of the few issues I still run into
regularly with aptitude.

- Josh Triplett