[Aptitude-devel] Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal

[Vincent Lefevre]

Hi Manuel,

On 2016-03-18 15:15:11 +0000, Manuel A. Fernandez Montecelo wrote:
> 2011-12-08 11:53 Vincent Lefevre:
> > The second solution is OK, as only a library package is removed, and
> > such a package with no dependencies on it is useless.
> 
> Not necessarily.  The library might have been installed by hand for
> extra sound plugins or other codecs, mesa libraries not strictly needed
> according to the dependency system but worthy to have in that machine,
> dvd decoding, or to support something installed in the system outside of
> the package managers (e.g. a special version of a webserver or other
> software, compiled in /usr/local, mounted through NFS, etc).
> 
> If it's not really installed for a special purpose, should have been
> marked as automatically installed to get rid of it sooner.

All my libraries are automatically installed. However some
automatically installed packages are not marked as automatically
installed. Perhaps due to some aptitude bug. I had reported a
bug in the past:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720386

Now, the fact that a library was automatically installed doesn't
mean that it is safe to remove. For instance:

1. The user installed libfoo-dev to compile a program using
   library foo. This automatically installs libfoo. It may also
   happens that both were already installed for some other reason
   (e.g. as a dependency).

2. The user compiles and installs his program.

3. After an upgrade, there is an ABI incompatibility in library foo,
   so that libfoo-dev now depends on libfoo3. At this point, there is
   no longer a dependency on libfoo, so that it will automatically be
   removed.

Of course, the user may have marked package libfoo as manually
installed, but I wonder whether most users do so. It is not always
obvious to know which library packages were needed.

Also, a long time after marking some library package as manually
installed, one may no longer remember the reason.

IMHO, the right thing to do would be to write some tool that manages
such dependencies, possibly in some automatic way (e.g. with ldd and
dpkg -S).

> I don't think that libraries should be treated that specially for
> reasons of removals as in the example of the original report.  "useless"
> doc packages or conflicts between icon sets might also come to mind as
> being favoured to remove in conflict resolutions -- after all not having
> doc installed usually doesn't break binaries ;-)

Icon sets may be regarded as something similar to libraries:
they are not directly used by the end user.

> But more seriously, I think that the real problem is prefering many
> removals and some keeps rather than a few upgrades and a single removal,
> but not because it's specifically a library involved in that.

A single removal is bad if it is an application.

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