During an upgrade with aptitude:

dpkg: dependency problems prevent removal of libmtp-common:
 libmtp9t64:amd64 depends on libmtp-common.
 libmtp-runtime depends on libmtp-common.

dpkg: error processing package libmtp-common (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libmtp-common

Note that "apt install -f" has nothing to fix; this upgrade just
triggered a dpkg error (similar to bug 1065603).

Moreover, like in bug 1065603, aptitude did not propose the removal
of libmtp-common:

Aptitude 0.8.13: log report
Thu, Mar  7 2024 15:49:03 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 11 packages, and remove 3 packages.
8192 B of disk space will be used
========================================
[...]
[HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3
[...]
[INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1
[INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1
[INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1
[REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2
[REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2
[REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3
[...]
[UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1
[UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1
========================================

Note that libmtp-common:amd64 1.1.21-3.1 was available, but for
some unknown reason, aptitude did not propose its upgrade.

Control: reassign -1 aptitude 0.8.13-6

This looks like another instance of 1065626. Reassigning to aptitude.

Cheers

Hi,

Today I upgraded one of my unstable machines and saw several instances of
something I believe is the same bug. The resolver seems to be failing to
choose to upgrade certain dependencies. What's more, in the aptitude GUI
I can see the rightmost "latest available version" column change on the fly
when I select certain packages for upgrade.

For example, I currently have libnm0 and libnm0:i386 installed at 1.46.0-1
and I can see the latest version is 1.46.0-2. If I go into the GUI and
choose
to "Install" libnm0, the latest version column for libnm0:i386 will change
from 1.46.0-2 to 1.46.0-1. Choosing "Install" on libnm0:i386 will then
effectively
do a keep of libnm0 at 1.46.0-1. To fix this, I can either go into
libnm0:i386 and
explicitly choose the newest version or I can restart the GUI and then it
will
list and choose the latest version correctly when I do Install libnm0:i386.

aptitude version: 0.8.13-6

Best,
Facundo

Hi,
what I was asking to. This is also what appears in the aptitude logs.
However, what really happened is something completely different:
libmtp-common was attempted to be removed while no such removal was
shown on the aptitude side (not even in its debug logs). This is not
an issue with the resolver, but what happens somewhere between aptitude
and dpkg.

The "the latest version column for libnm0:i386 will change from
1.46.0-2 to 1.46.0-1" with the TUI corresponds to

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

which I had reported 3 years ago and still occurs regularly.

Concerning the buggy dependency resolutions (showing that aptitude
does not favor the most obvious solutions, whether the TUI is used
or not):

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

Control: severity -1 important
Control: user release.debian.org@packages.debian.org
Control: usertags -1 time-t-downgrade

This bug has since been reassigned to aptitude. Solver limitations
in aptitude wrt t64 handling should not be considered release critical,
it makes no sense to remove aptitude from testing for it; there are
still plenty of other valid use cases that are unaffected by these
particular bugs, so I am downgrading it to important.

OK, but note that this is a rather serious bug somewhere (perhaps
in aptitude, but really, I'm not sure since according to aptitude's
debug log, everything is fine on its side), not just a solver
limitation: if this were a solver limitation, aptitude would have
at least said that the upgrade was not possible because some
dependency could not be satisfied (this is what it usually does);
but this is not what happened.

In short, something attempts to remove a package that has *not*
been marked as to be removed. Fortunately, when trying to remove
the package, dpkg detects a dependency issue. But I fear, that in
some cases (e.g. when the unannounced package to be removed would
not have a dependency on it), this could potentially completely
break the system.