[Aptitude-devel] Bug#740009: aptitude: auto-installed package, depended on by non-installed virtual package provider, not removed

[Daniel Hartwig]

On 25 February 2014 05:43, Zack Weinberg <zackw at panix.com> wrote:
> Package: aptitude
> Version: 0.6.10-1
> Severity: normal
>
> On a (deliberately minimal) system with bsd-mailx, nullmailer, and
> libpcre3 installed, but nothing that actually depends on libpcre3
> installed, and libpcre3 set to auto-installed, libpcre3 will not be
> autoremoved,

How are you attempting to autoremove the package?  Aptitude performs
this task as the opportunity presents itself, though there are some
known issues.  Usually running "aptitude install" without further
arguments is sufficient.

> because:
>
> # aptitude why libpcre3
> i   bsd-mailx          Depends  default-mta | mail-transport-agent
> p   exim4-daemon-light Provides mail-transport-agent
> p   exim4-daemon-light Depends  libpcre3 (>= 8.10)
>
> It looks as if the dependency solver is not paying attention to which
> concrete package is satisfying bsd-mailx's dependency on
> mail-transport-agent on this system.

The output from "why" is not related to the dependency solver or
autoremoval of packages.  It simply finds the most relevant reason it
can (refer to man page for details) to install or keep installed the
specified package, and this may or may not involves packages that are
actually installed.

In your situation, there is no fully installed dependency chain and
the reason shown by this command is not keeping the package from being
removed.

> A manual 'aptitude purge
> libpcre3' went through without complaint.
>