[Aptitude-devel] Bug#653284: unreasonable "Do not install"

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Harri,

2011-12-26 13:01 Harald Dunkel:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Package: aptitude
>Version: 0.6.4-1.2
>
>If I try to install a single package "A" using
>
>	aptitude update
>	aptitude upgrade
>	aptitude install A
>
>and run into a conflict with already installed packages,
>then aptitude shows me several optional configurations to
>resolve the conflict.
>
>But why does it show me so many different package configu-
>rations adding and removing tons of other packages, _not_
>touching A's current state ("Not Installed")?

I don't know if I understand very well what you say, because the subject
seems to contradict what I understand from the above (would be more
like: "Unreasonable try-too-hard-to-install rather than keep requested
uninstalled").

In general, I think that the bug is not very actionable as it is.


For example, from your example above, you might want to install
A=awesome-media-player-ng that conflicts with awesome-media-player.  So
aptitude, seeing that you want the new awesome-media-player-ng
installed, it offers several solutions, including possibly removing tons
of libraries or upggrading them, to try to keep you happy.

After searching for a while to try to satisfy your request, maybe it
decides that upgrading some libraries is better than not touching them
at all, even if your request cannot be granted, because in the
calculations about costs and benefits it thinks that there's a net gain
in going ahead with the given solution.  The solutions might be
unintuitive, because maybe it reaches the conclusion that upgrading 3 is
not worth it (ranks worse than some other solution), but upgrading 6 is
good because it's just over a point higher than the next solution.

I think that the nature of the resolver leads to these "open solutions"
when anything can be valid or not, depending on the specific case.

If the system has multi-arch enabled, or you mix several of
stable/testing/unstable/experimental, and there are ongoing library
transitions involved in the conflicts, and depending on the pinning and
all that, the situation becomes very unwieldy and difficult to reason
about very quickly.  The suggestions that it gives can be very stupid
sometimes.


After reading hundreds of bug reports and seeing these cases mentioned
more than once, the reason why it tries very hard to install what you
requested is (according to the original developer) because it assumes
that you know what you are doing and that you really want to install it,
and it doesn't know if the packages that conflict and have to be removed
are more important to you or not that the one that you want to install,
or if your new package is worth 3 removals that you don't care about,
but not 1 removal which you do care about.  Sometimes, even the one that
you requested can be uninstallable, but aptitude keeps trying to give
suggestions.

Not having delved at all in the mysterious inner mechanisms about how
aptitude resolver works [*], I think that this is because it reaches a
partial solution where some packages need to be
upgraded/removed/whatever, then it decides that A cannot be installed
anyway, so the solution in the end is to suggest to upgrade or remove a
bunch of packages even if the one that you requested cannot be
installed, because they rank better than what one would expect that it
would be the default solution (not touching any package).  Maybe the
should-be-default ranks lower than the others because it was given a big
negative score for not honouring your request.

  [*] and it did change a lot during the years where the original
      developer was active, so maybe the explanation that he gave in a
      bug in 2007 about why the resolver works in one way was invalid by
      the next release
  

There might be several causes underlying this.  There are still bugs
currently open about aptitude not trying hard enough to do what the user
requests (and there were others closed in the past), so maybe the
original developer pushed too far in this direction because of users
requesting this insistently.  Changing this behaviour by now is always
risky, because it can trigger another set of problems that could be
worse than the current ones.

Similar case is the one commented that maybe once the resolver kicks in,
it reaches the conclusion that upgrading packages (even if A is not
touched) is a net positive because upgrades are sanctioned as "good",
for example, so they rank better in the solutions (with the default
costs) that not doing anything at all.  Tweaking the resolver costs to
change this behaviour is also tricky for the same reasons.

Another reason might be that simply there's a bug (or many!), but for
that we need to have a clear example of packages where this happens, and
then have somebody brave enough to dive into the abyss.

That's why I think that the bug as it is is not very actionable.


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