[Debian-med-packaging] Bug#959409: pbcopper breaks pbbam (autopkgtest): libpbcopper.so.1.3.0: cannot open shared object file: No such file or directory

[Adrian Bunk]

Control: reassign -1 libpbcopper1.3.0 1.4.0+dfsg-1
Control: affects -1 src:pbbam

On Sat, May 02, 2020 at 08:09:09AM +0200, Paul Gevers wrote:
>...
> I copied some of the output at the bottom of this report. To be honest,
> this looks a bit messy. 1) libpbcopper.so.1.4.0 is shipped by a package
> called libpbcopper1.3.0 (this may be correct, but very confusing; didn't
> investigate further). 2) pbmerge is opening libpbcopper.so.1.3.0 instead
> of something like libpbcopper.so.1 (and following symlinks). This may be
> correct (again, I didn't investigate), but it makes updates to pbcopper
> very fragile (as in this case) and isn't what normally happens with
> libraries, where the symlinks make it possible to update the package
> without rebuilding if SONAME compatibility is maintained, and otherwise
> trigger a transition that can be handled by the release team.
>...

$ objdump -p /usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0 | grep SONAME
  SONAME               libpbcopper.so.1.6.0
$

With this SONAME, which looks correct if ABI changes with each 1.x.y
release, the general package naming is correct.

But the transitions
   libpbcopper.so.1.3.0 -> libpbcopper.so.1.4.0 -> libpbcopper.so.1.6.0
were missing and shipping libpbcopper.so.1.6.0 in libpbcopper1.3.0
is wrong and breaks reverse dependencies.

Reassigning to the package that is at fault here.

cu
Adrian