Package: libcares2 Version: 1.33.1-1 Severity: normal X-Debbugs-Cc: vor...@debian.org
The package containing libcares.so.2 was renamed during the t64 transition (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062032, https://salsa.debian.org/debian/c-ares/-/commit/6972270af2b7d53a2be08ca0059b17476a628d95 ) and at that time, instead of being renamed from libc-ares2 to libc-ares2t64, Steve took the opportunity to rename it from the non-standard libc-ares2 to the Policy-compliant name libcares2. However, it already had a "Conflicts: libcares2" which was preserved during that rename. The addition of that Conflicts was before the beginning of git history, but it seems to have been added in order to force removal of a historical unofficial package from outside the Debian archive (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478588#10). If a package Conflicts with itself, apt/dpkg allows it to be installed, but only for one architecture at a time, making the Multi-Arch: same field ineffective. This prevents libcares2 and higher-level libraries that depend on it from being co-installed. For example, the situation that made me trip over this was inability to co-install the libear:amd64 and libear:i386 used by the bear package if you are building both amd64 and i386 code, because they have the dependency chain libear -> libgrpc29t64 -> libcares2. I think the solution is to just delete the "Conflicts: libcares2" (untested, but should work). libcares2 correctly has a Breaks/Replaces on libc-ares2, so it will correctly replace the pre-t64 version of itself. Thanks, smcv
