Bug#1102279: lib{,n}32atomic1 have an undeclared file conflict on /usr/lib32/libatomic.so.1*

that might be a question for syq, or mips porters ...

On 07.04.25 09:39, Helmut Grohne wrote:
> Package: lib32atomic1,libn32atomic1
> Version: 15-20250329-1
> Severity: serious
> User: [email protected]
> 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
>