Hi,

this bug report was triggered by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099706#20

It appears, that when moving functionality from one package
(old_package) to another package (new_package) a lot of maintainers
update their dependencies like this (a/):

Depends/Recommends/Suggests: new_package | old_package

Now, if I install new_package, "apt autoremove" will not consider the
removal of old_package even though there is no reason anymore to keep
this package installed.

A case in point is dbus having a "Pre-Depends: base-files | usr-is-merged"
in trixie at this point.
This prevents the usr-is-merged package to be autoremoved.

While dropping this alternative dependency on usr-is-merged is currently
discussed, I think apt could handle such a situation in a more clever
way as this seems to be a more widespread issue.

Another recent example I can think of is the transition from policykit-1
to polkitd, where quite a few packages had a "polkitd | policykit-1"
dependency due to the recommendations suggested in e.g. b/

Thanks for considering,
Michael


a/ I assume this is done to make backports simpler
b/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025595
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-utopia-maintainers@lists.alioth.debian.org&tag=policykit-1

Yes this is very much intentional. Let's take a different example:

    foo: Depends: database-backend-a | database-backend-b

You have installed foo and configured it to use the b backend, because
back in the day it was the default.

Now you install bar

    bar: Depends: database-backend-a

Removing database-backend-b would break foo.

Now, my new solver implements the behavior you are after in the 3.1
level, so apt autoremove --solver 3.1 will only consider the "best"
choices (usually the most left one, unless something else picked
another one earlier).

Given the drastic shift in behavior it's not clear whether this
can become the default or whether we should stick to a safe
autoremoval code, and hide this in autoremove --deep/--strong/idk.

An argument can be made that given a depends with multiple solutions,
we should not follow ones in "oldlibs" if there are others, I'll leave
that thought for further consideration.