Bug#1101291: coinstallation failure of various llvm-toolchain-snapshot packages

[Simon McVittie]

Control: tags -1 + patch
Control: clone -1 -2 -3
Control: retitle -1 Multi-Arch coinstallation failure of various llvm-toolchain-21 packages
Control: reassign -2 liboffload-20
Control: retitle -2 Multi-Arch coinstallation failure of liboffload-20
Control: reassign -3 src:llvm-toolchain-snapshot

On Tue, 25 Mar 2025 at 07:30:55 +0100, Helmut Grohne wrote:
>The named packages fail to coinstall despite explicitly declaring that
>capability via Multi-Arch: same. Most of them install
>architecture-dependent files to architecture-independent filenames below
>/usr/lib/llvm-21/lib. Please either move those files to multiarch
>locations or remove the Multi-Arch: same annotations.

Since this bug was opened, the packages named in Helmut's report have 
been moved to src:llvm-toolchain-21, and llvm-toolchain-snapshot is now 
version 22. llvm-toolchain-20 has also gained a new package, 
liboffload-20, which is declared as Multi-Arch: same but actually is 
not: all architectures' instances of it contain 
/usr/lib/llvm-20/lib/libLLVMOffload.so.20.1, with different contents.

In the short term I think the best answer to this is to remove the 
"Multi-Arch: same" field from each package that is not co-installable, 
which would allow this RC bug to be closed - but while making sure to 
leave "Multi-Arch: same" set on libllvm${VERSION}, to avoid the 
equivalent of #1106132 and #1115227.

As a longer-term solution, it would be nice if these packages could 
become genuinely "Multi-Arch: same" with no colliding files, as I 
requested in #1111182, but that is only a wishlist request and not a RC 
bug, and will involve more changes than simply fixing the RC bug. I'll 
try to follow up to that wishlist request later.

Because the LLVM packaging has several source packages and bug-fixes in 
one of them are not always merged or cherry-picked to the others, I 
would suggest that applying equivalent changes to all of the active 
branches at around the same time would be a good way to ensure that this 
doesn't regress.

I have prepared merge requests for the 20, 21 and snapshot (22) 
branches which I believe are correct:

* 20: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/186
   (closes: cloned bug -2, I will update the branch to include the bug
   number when I have it)
* 21: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/187
   (closes: #1101291)
* snapshot: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/188
   (closes: cloned bug -3, I will update the branch to include the bug
   number when I have it)

Each of these merge requests includes new tests in 
debian/qualify-clang.sh similar to the ones that were merged to the 19 
branch in 
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/184, 
to assert that:

1. libllvm${VERSION} remains M-A: same, avoiding regressions that are
    the equivalent of #1106132 and #1115227
2. each package with files in /usr/lib/llvm-${VERSION}, except for
    libclang-common-${VERSION}-dev, is *not* M-A: same, avoiding
    regressions that are the equivalent of this bug

Please consider applying those changes. I have not done an end-to-end 
test of them with a full LLVM build because of the computing resources 
required to build LLVM in a clean environment, but I belive they are correct.

This seems to be a recurring regression in the llvm-* family of 
packages, so it would be great if the extra checks in 
debian/qualify-clang.sh can stop it from regressing again in future.

Thanks,
     smcv