Package: lib32atomic1,libn32atomic1 Version: 15-20250329-1 Severity: serious User: debian...@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
