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
