1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1099766: Make autoremove consider alternative dependencies

    From Michael Biebl@21:1/5 to All on Fri Mar 7 20:40:02 2025
    Package: apt
    Version: 2.9.31
    Severity: wishlist


    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Andres Klode@21:1/5 to Michael Biebl on Sat Mar 8 00:10:01 2025
    On Fri, Mar 07, 2025 at 08:31:46PM +0100, Michael Biebl wrote:
    Package: apt
    Version: 2.9.31
    Severity: wishlist


    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.

    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.
    --
    debian developer - deb.li/jak | jak-linux.org - free software dev
    ubuntu core developer i speak de, en

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)