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

[Vincent Lefevre]

On 2016-04-01 16:24:47 +0100, Manuel A. Fernandez Montecelo wrote:
> If you didn't have several versions enabled at the same time, libecm0
> would maybe be detected as "obsolete" and maybe then apt-get
> dist-ugprade would decide to go ahead with the upgrade and remove the
> obsolete package.  But since your package is marked as manually
> installed, it probably does not try to remove it anyway, even if it
> was "obsolete".

After explicitly marking the package as auto:

i A libecm0                    6.4.4+ds-5               6.4.4+ds-5

I have the same problem when I want to upgrade.

$ aptitude why gmp-ecm
i   libecm0-dev Depends    libecm0 (= 6.4.4+ds-5)
i A libecm0     Recommends gmp-ecm (= 6.4.4+ds-5)

Well, that's libecm0-dev which is manually installed, but there
isn't much choice. The intent of an upgrade would be to replace
it by libecm1-dev.

When I type 'U' in the aptitude UI, I get:

idA gmp-ecm          -186 kB   6.4.4+ds-5               7.0+ds-1                

The first time, when I typed 'g', there was some other broken package
(due to the fact that libdconf-dbg no longer exists, thus not related
to gmp-ecm), and aptitude automatically undeleted gmp-ecm, which was
fine but but user could wonder why aptitude behaved inconsistently.

After resolving the issue with libdconf-dbg (basically removing it
and upgrading the *dconf* packages), when I type 'g', aptitude no
longer undeletes gmp-ecm, so that the Recommends is silently broken.

I also wonder what you mean by "several versions enabled at the same
time" above. If you mean several releases in /etc/apt/sources.list,
the non-default ones are just there to be able to install alternate
versions on *explicit* request; anyway, if aptitude chose to remove
gmp-ecm because it considered the old version as obsolete, then
there's no reason to do differently with libecm0-dev. Anyway, I've
tried after keeping only the unstable lines in sources.list then
"apt-get update", and aptitude had the same behavior, both with the
UI and with the command line:

# aptitude upgrade -s
The following packages will be REMOVED:  
  gmp-ecm{u} 
0 packages upgraded, 0 newly installed, 1 to remove and 14 not upgraded.
Need to get 0 B of archives. After unpacking 186 kB will be freed.

Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] 
Would download/install/remove packages.

Also, note that I still have:

Aptitude::ProblemResolver::SolutionCost "safety, removals";

which would be a reason not to remove any package except auto
packages with no reverse dependency.

> What aptitude was doing until recently when requesting to upgrade
> gmp-ecm was to upgrade it and unmark it as auto (because otherwise it
> would be removed, as it happens now).  It was one of the sources of
> the "silently looses auto flags", it seems.
> 
> So there are 3 possibilities: old behaviour (upgrade, ignore broken
> recommends and set no-auto), current behaviour (upgrade ignoring
> broken recommends but preserve auto, which in this case results in
> removal because of "unused"), silently ignoring the upgrade request,
> emitting an error, or invoking the resolver.

I don't understand why this is all complicated. Since aptitude
already knows how not to break strong dependencies ("Depends"),
why can't it do exactly the same for "Recommends" when
APT::AutoRemove::RecommendsImportant is in effect?

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