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

[Vincent Lefevre]

Hi,

On 2016-03-31 21:05:57 +0100, Manuel A. Fernandez Montecelo wrote:
> 2016-03-31 12:55 Vincent Lefevre:
> > 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).

Yes, I wanted to know why gmp-ecm had automatically been installed.

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

Note that *only* gmp-ecm is marked for removal, not libecm0.
And libecm0 6.4.4+ds-5 still recommends gmp-ecm (= 6.4.4+ds-5).
So, if aptitude doesn't remove libecm0, the above logic is broken.

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

No:

ypig:~> aptitude upgrade -s
The following packages will be REMOVED:  
  gmp-ecm{u} 
0 packages upgraded, 0 newly installed, 1 to remove and 8 not upgraded.
[...]

ypig:~> aptitude safe-upgrade -s
The following packages will be REMOVED:  
  gmp-ecm{u} 
0 packages upgraded, 0 newly installed, 1 to remove and 8 not upgraded.

ypig:~> aptitude full-upgrade -s
The following packages will be REMOVED:  
  gmp-ecm{u} 
0 packages upgraded, 0 newly installed, 1 to remove and 8 not upgraded.

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

This rather contradicts what David Kalnischkies says about Recommends
in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489896#12>:

"Recommends are installed by default by design as this is what the Debian
policy requires.

Not installing them (even while fixing up broken systems) means that we
leave the system "slightly broken" as recommend packages should be
installed… so, mot a bug, but by design."

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

I don't have any such option.

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

If this is OK, this means that "Recommends" is too strong, or the
dependency is incorrect (e.g., it should be: www-browser | ...).

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

Note that I didn't say that I wanted to upgrade the package, but
to upgrade the system. Since libecm1 is the successor of libecm0,
the right thing would have been to propose the upgrade to libecm1
(ditto for the -dev package). BTW, what will happen with the next
Debian/stable? Will the user be prevented from upgrading to the
new gmp-ecm packages by "apt-get dist-upgrade"?

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

I think that the right solution would be to warn the user before
breaking Recommends. In any case, never break Recommends if this
is not necessary.

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

I've just reported a bug.

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

Actually I prefer unstable, but don't want to break Recommends
(since this may break things).

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

I don't want to mark it as manually installed, since it is OK to
remove it as soon as there is no longer any rev dependency.

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

In fact, libecm0 is automatically installed, and libecm0-dev is
manually installed (and depends on libecm0).

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

Yes, but aptitude shouldn't have proposed to remove gpm-ecm in the
first place.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)