Source: llvm-toolchain-20 Version: 1:20.1.8-1~exp1 Severity: normal X-Debbugs-Cc: [email protected], Andres Salomon <[email protected]> Control: affects -1 src:libunwind
We have two things named libunwind in debian: 1. src:libunwind upstream: https://github.com/libunwind/libunwind SONAME: currently libunwind.so.8 libdevel: libunwind-dev libs: libunwind8 (as per Policy §8.1) 2. The libunwind provided by LLVM upstream: https://github.com/llvm/llvm-project SONAME: currently libunwind.so.1 libdevel: libunwind-{19,20,21,22}-dev libs: libunwind-{19,21,22} libs: libunwind (no suffix) from src:llvm-toolchain-20 since 1:20.1.8-1~exp1 It seems very confusing that "libunwind" as a source package name is the independent libunwind, but "libunwind" as a *binary* package name is LLVM's libunwind. In particular this confuses the bug tracking system (https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libunwind says that "Maintainers for libunwind are LLVM Packaging Team <[email protected]>" which is not actually a true fact about src:libunwind) and can easily confuse bug submitters too (for example the nmudiff #1093709 was sent to the wrong package). Because LLVM's libunwind has SONAME libunwind.so.1, I would suggest giving it its Policy-compliant binary package name, libunwind1, as per Policy §8.1 (https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries), which would reduce confusion with the other libunwind. It currently only exists in experimental, so this shouldn't have a problematic binary-compatibility impact yet. Unfortunately this will require another trip through the NEW queue. If there are any other libraries in LLVM whose binary package names do not match their SONAMEs, going through NEW for libunwind1 could be a good opportunity to fix those up too. (If the LLVM upstream maintainers ever bump the SONAME of their libunwind, presumably to libunwind.so.2, then the binary package would need a rename for that *anyway* for the reasons given in Policy §8.1 - although it would perhaps be more helpful if they could be encouraged to name it something more like libllvm-unwind.so.* next time there is a compatibility break, to avoid confusion with the other libunwind.) smcv
