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
