Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: transition
Control: block -1 by 908815
X-Debbugs-Cc: Roberto Lumbreras <ro...@debian.org>
As discussed with jmw at the Cambridge BSP, libdmtx0a has broken ABI
without changing its SONAME (#908815). Judging by the name, this isn't the
first time. The quickest way to a correct situation in buster seems to
be a transition to a new binary package name libdmtx0b that represents
the new ABI, which is currently waiting in NEW for experimental.
Ben file:
title = "libdmtx";
is_affected = .depends ~ "libdmtx0a" | .depends ~ "libdmtx0b";
is_good = .depends ~ "libdmtx0b";
is_bad = .depends ~ "libdmtx0a";
Only a few packages are affected:
dmtx-utils: dmtx-utils
openrpt: libopenrpt1v5
openrpt
postbooks: postbooks
prison-kf5: libkf5prison5
visp: libvisp-detection3.1
In addition, dmtx-utils 0.7.6-1.1 will need to be unblocked (it just
removes a hard-coded libdmtx0a dependency so that the binNMU will be
installable: #924254). I've verified that dmtx-utils 0.7.6-1.1, when
rebuilt against libdmtx0b, gets a libdmtx0b (>= 0.7.5) dependency and
passes some simple tests.
For future Debian releases, it would be helpful if the maintainer of
libdmtx could teach their upstream about ABIs[1], and be extra-careful
to check for compatibility when importing new upstream releases. Adding
autopkgtests might also be useful: if updating libdmtx had caused the
old dmtx-utils to fail its tests, then we might have detected this sooner.
Thanks,
smcv
[1] Maybe useful:
https://events.static.linuxfound.org/sites/events/files/slides/Binary_Compatibility_for_library_devs.pdf
