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

[Manuel A. Fernandez Montecelo]

2016-03-22 13:27 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

Yeah, there were dozens of bugs like that.  Some were addressed a while
ago and some are WIP, but still a few/many problems still remain.


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

Package manager tools don't have any knowledge of the system outside of
the dependencies, so if there are local software needing packages (be
that a library or any other package/command, the same bad effects happen
if other packages get removed) only the user can act upon that.

About your phrase if "a library was automatically installed doesn't mean
that it is safe to remove", seems to argue about the very title of this
report and what you were saying in it ("The second solution is OK, as
only a library package is removed, and such a package with no
dependencies on it is useless"); and goes in favour of what I was saying
in the previous message -- I don't think that libs should be favoured to
be removed in conflict resolutions, as originally proposed.

(Besides, deciding which packages are libraries is not trivial nor
accurate, there are many packages badly classified as section "libs"
which are not libs or the other way around; and weirdness with non-C/C++
languages).


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

If the user cannot, the packaging system cannot know either.

Still, either we remove completely the mechanism of auto-installed
(which will not happen) or we have to admit that removing as soon as
there are no rev-deps is the best thing to do, and the way that this
auto-installed thing was designed to work (and copied to apt afterwards,
I believe).

If this is somehow undesired, one can always resort to manage all
packages manually.


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

That's not the job of a tool like aptitude, though.

It's would be relatively easy to build such a tool and then regularly to
call apt/aptitude to unmark such packages as auto; or possibly hook on
apt updates a-la apt-listchanges or apt-listbugs.


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

That's strange coming from you, who use the resolver costs of minimizing
removals ;-)

aptitude and apt have sometimes to remove, not install or do other nasty
actions when packages conflict, there's no way around that.  Removals
are critical to deal e.g. with obsolete packages and upgrades, even if
the removal of that library could end up breaking packages (your example
above).

My sentence above was about the original report.  If removals are
necessary, as they were in that case, better /offer first/ to remove 1
and upgrade 11 than to remove 20 and leaving others untouched (the 2
solutions mentioned in the original report).

If the user is not happy with the offer, s/he can always ask aptitude
for another solution, and reject those who doesn't like to guide the
resolution quickly towards a desired outcome.


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