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

Sat Jun 11 17:57:14 UTC 2016

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.

"apt install libreoffice-writer/experimental" just refuses to upgrade,
unless -t is provided.  aptitude at least invokes the resolver and
lets the user to guide it to a satisfactory conclusion.

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

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

I prefer to see it as "aptitude's resolver puts people in charge, and
it's for those which are not bothered to press a few keys to get it to
do what they want".

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

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