Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1212425 > unrolled thread

Bug#1081454: libcares2: "Conflicts: libcares2" prevents multiarch co-installation

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1081454: libcares2: "Conflicts: libcares2" prevents multiarch co-installation Simon McVittie <smcv@debian.org> - 2024-09-11 20:30 +0200
    Bug#1081454: libcares2: "Conflicts: libcares2" prevents multiarch co-installation Gregor Jasny <gjasny@googlemail.com> - 2024-09-22 11:50 +0200

#1212425 — Bug#1081454: libcares2: "Conflicts: libcares2" prevents multiarch co-installation

Package: libcares2
Version: 1.33.1-1
Severity: normal
X-Debbugs-Cc: vorlon@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

[toc] | [next] | [standalone]

#1213932

Hello Simon,

thanks for reporting this issue and also for doing the code archeology.

On 11.09.24 20:17, Simon McVittie wrote:
> However, libcares2 already had a "Conflicts: libcares2" which was preserved during
> that rename.
> 
> I think the solution is to just delete the "Conflicts: libcares2"
> (untested, but should work).

I agree with your suggestion and uploaded a fixed version.

Thanks,
Gregor

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web