Package: lib32atomic1,libn32atomic1
Version: 15-20250329-1
Severity: serious
User:
debian-qa@lists.debian.org
Usertags: fileconflict
Hi Matthias,
I observe that lib32atomic1 and libn32atomic1 both install /usr/lib32/libatomic.so.1 and /usr/lib32/libatomic.so.1.2.0 without
declaring any suitable relation for preventing concurrent unpack. There
is no practical way of actually installing both as they depend on the
multilib libc which declares conflicts across those architectures, but
that dependency does not prevent concurrent unpacks. Please have
libn32atomic1 declare Conflicts: lib32atomic1 or the other way round.
When doing so, please be careful to not impact cross toolchains. The transformed packages lib32atomic1-amd64-cross and
libn32atomic1-mips64el-cross are actually coinstallable and should
remain coinstallable. It is the dpkg-cross transformation that moves
around the files into sysroots that makes these coinstallable.
This problem likely applies to other lib32* and libn32* gcc libraries
such as lib32gcc-s1, lib32gfortran5, lib32go24, lib32gomp1,
lib32gphobos2, lib32objc4 and lib32stdc++6. You may fix those as well
and we shall see what remains.
Would you happen to understand why those mipsen packages are called
libn32* and yet install to /usr/lib32 rather than /usr/libn32 as I would understand from their package name? It may be a historical accident and
no longer fixable at this time, but I'd still appreciate understanding
that inconsistency.
Helmut
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)