[Aptitude-devel] Bug#819636: aptitude: wants to remove a recommended package

Thu Mar 31 20:05:57 UTC 2016

Hi,

2016-03-31 12:55 Vincent Lefevre:
>Package: aptitude
>Version: 0.7.8-1
>Severity: important
>
>On upgrade from the UI, aptitude wants to remove the gmp-ecm package.
>The given reason is:
>
>gmp-ecm was installed automatically; it is being removed because all of the    ▒
>packages which depend upon it are being removed:                               ▒
>
>and no packages are listed!!!
>
>ypig:~> aptitude why gmp-ecm
>i   libecm0 Recommends gmp-ecm (= 6.4.4+ds-5)

Side note: If I recall correctly, "aptitude why" explains the current
state of the system, not taking upgrades into account, so this
information does not necessarily explain anything when upgrading (e.g.,
a new version of libecm0 could have stopped recommending the package).

Anyway, if in the upgrade action gmp-ecm (auto-installed) is marked for
upgrade and there are no packages depending on that version, it will get
marked as auto-removed.

I hope that at least if the equivalent package which depends on the
newer gpm-ecm (libecm1) is installed, or any other package which indeed
depends/recommends the newer gpm-ecm, it would most probably be marked
for upgrade and not be removed.

(more on this below)

>However, for the proposed upgrade, libecm0 is not upgraded/removed.
>
>ypig:~> apt-show-versions -a libecm0
>libecm0:amd64 6.4.4+ds-5 install ok installed
>libecm0:amd64 6.4.4-2    stable   ftp.fr.debian.org
>No stable-updates version
>libecm0:amd64 6.4.4+ds-5 testing  ftp.fr.debian.org
>libecm0:amd64 6.4.4+ds-5 unstable ftp.fr.debian.org
>No experimental version
>libecm0:amd64/testing 6.4.4+ds-5 uptodate
>libecm0:i386 6.4.4-2    stable   ftp.fr.debian.org
>No stable-updates version
>libecm0:i386 6.4.4+ds-5 testing  ftp.fr.debian.org
>libecm0:i386 6.4.4+ds-5 unstable ftp.fr.debian.org
>No experimental version
>libecm0:i386 not installed
>
>ypig:~> apt-show-versions -a gmp-ecm
>gmp-ecm:amd64 6.4.4+ds-5 install ok installed
>gmp-ecm:amd64 6.4.4-2    stable   ftp.fr.debian.org
>No stable-updates version
>gmp-ecm:amd64 6.4.4+ds-5 testing  ftp.fr.debian.org
>gmp-ecm:amd64 7.0+ds-1   unstable ftp.fr.debian.org
>No experimental version
>gmp-ecm:amd64/testing 6.4.4+ds-5 upgradeable to 7.0+ds-1
>gmp-ecm:i386 6.4.4-2    stable   ftp.fr.debian.org
>No stable-updates version
>gmp-ecm:i386 6.4.4+ds-5 testing  ftp.fr.debian.org
>gmp-ecm:i386 7.0+ds-1   unstable ftp.fr.debian.org
>No experimental version
>gmp-ecm:i386 not installed
>
>but "apt-get dist-upgrade -s" says that gmp-ecm can't be upgraded.

What I think that it's happening is that "apt-get dist-upgrade" forbids
from upgrading gmp-ecm because otherwise libecm0 gets a recommendation
unfulfilled and apt-get considers that a broken system; while aptitude
thinks that you prefer to upgrade gmp-ecm whatever the cost (and
subsequently marks it for removal due to lack of rev-deps for the
upgraded version).

Probably "aptitude safe-upgrade" and "aptitude full-upgrade" give
different results on this as well.

In the curses interface most probably aptitude prefers to upgrade+remove
gmp-ecm because if it was explicitly marked for upgrade by the user (and
not a decision of the resolver), or it prefers that solution to others
(like removing N packages instead of 1).

If the above is indeed what happens, the end result is not very useful
in this particular case; but from aptitude's POV if the user marks for
upgrade is because it doesn't want the current version of gpm-ecm.
Therefore, keeping the current version of gpm-ecm is not considered a
good option, and aptitude might break the recommends as a lesser evil
[1].  If all options related to installing Recommends are set to true,
maybe it should present the "conflicts resolver" screen to choose
between upgrading or keeping both at the same version, not just mark
gpm-ecm for removal, I don't know if this is the case?  But upgrading
gmp-ecm and not breaking the recommends is impossible, in any case.

[1] esp. if Recommends are somehow told that it's not important, with
    e.g. RecommendsImportant, Install-Recommends or related options set
    in one way or another.

Maybe with this pair of packages the decision doesn't make a lot of
sense, but there are other similar cases in which it can do.  E.g. if
-doc packages or desktop-help recommend browsers at particular versions,
for example, and if you mark the browser for upgrade, you wouldn't want
to stop upgrading your browser just because some -doc packages are
recommending an older version (might happen with iceweasel->firefox
rename in the near future).

In particular, it seems that while you keep this package installed,
"apt-get dist-upgrade" will not allow you to upgrade gmp-ecm at all
until you remove libecm0, which doesn't sound very useful for the user
either if it indeed wants to ugprade that package.

These kind of behaviours are particularly important for dist-upgrades
from stable to next stable, when many packages can be left behind as
obsolete packages (or local packages installed by the user from
elsewhere), and recommend non-existent packages in the new stable.

About this particular case, there are some odd factors influencing this
behaviour:

- the "libecm0 Recommends gmp-ecm (= 6.4.4+ds-5)" is slightly odd.
  libecm0 can Recommend (or maybe just Suggest) gpm-ecm, but requiring
  an exact version doesn't make a lot of sense.

  It's almost surely not required to have an exact version, they most
  probably just added it because since it comes from the same source,
  and if only one suite of Debian is used at a time, it works fine.

  If several suites are used at the same time, then there are several
  libecmX in the system, and they require a different "exact version" of
  the same package, things cannot work very well.

- mark some suite as having more priority than the others, so aptitude
  doesn't consider all the suites equally valid for resolution. from the
  original report:

  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'),
      	      (500, 'unstable'), (500, 'testing'), (500, 'stable'),
	      (1, 'experimental')

  e.g. if you prefer "stable" and mark pin priorities accordingly,
  gmp-ecm would not be marked for ugprade.  "libecm0" and "libecm1"
  depending on a different version of gmp-ecm should not co-exist, in
  the mind of the maintainers who set the dependencies like that.

  however, as things are in your system, all versions of all packages
  are the same for aptitude, and it has a harder time making the right
  decision (or makes some decisions impossible at all).

There are several solutions which you most probably are aware about, but
anyway, maybe for others who stumble upon the same problem:

- if you really want gpm-ecm, mark it as manually installed.  (it's a
  bit odd that you have that one as auto and libecm0 as manual, when
  normally it's the other way around, but I assume that it's on
  purpose).

- if you want to stay with libecm0 for some reason, gmp-ecm will never
  be upgraded.  you can set a Hold to avoid constant nagging.

- you can upgrade to libecm1 instead, and gpm-ecm will be upgraded as
  well

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