Hello Andrea,
thanks for your bug report and also the analysis. I was able to
reproduce the bug.
while testing bookworm -> testing upgrades, I noticed that libc-ares2
doesn't get updated as expected and instead remains at 1.18.
Having libc-ares-dev installed in addition to the runtime package
seems to force the apt resolver to consider the upgrade, so in that
case the expected happens: libcares2 1.34 is installed and libc-ares2
1.18 is removed.
Note that, while on a minimal system with just libc-ares2 installed
the update is silently skipped in the first case, if some rdeps are
present they might be explicitly listed as held. This is how I
noticed this problem in the first place: libvirt-wireshark, which
depends on wireshark which in turn depends on c-ares, was not being
upgraded along with the other libvirt packages.
I wouldn't be suprised if this was a side effect of addressing
#1081454, but I'll leave the rest of the analysis to you.
After reading https://wiki.debian.org/RenamingPackages I believe the
"Clean slate method" applied for the t64 transition only worked due to
the self-conflict that was removed in #1081454. To fix the situation I'd
like to introduce a transitional package. The necessary commit is in
https://salsa.debian.org/debian/c-ares/-/commit/6f535f8e734c2ba9dbedc411e481ba82293608f4
Unfortunately, as a DM, I'm not allowed to add new packages.
@Simon, would you please consider sponsoring my upload? I uploaded it to
mentors: https://mentors.debian.net/package/c-ares/
Thanks,
Gregor
