Bug#1116211: libunwind: binary package for LLVM libunwind is confusingly named, should probably be libunwind1

[Simon McVittie]

Source: llvm-toolchain-20
Version: 1:20.1.8-1~exp1
Severity: normal
X-Debbugs-Cc: libunwind-dev at packages.debian.org, Andres Salomon <dilinger at debian.org>
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 
<pkg-llvm-team at lists.alioth.debian.org>" 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