[pkg-xtuple-maintainers] Bug#798247: ABI breakage

Daniel Pocock daniel at pocock.pro
Mon Sep 7 10:07:55 UTC 2015


Package: openrpt
Version: 3.3.10-2
Severity: important

I had a look at the diff between upstream v3.3.7 and v3.3.10 tags and I
notice changes to header files that appear to break ABI compatibility.

Any such change should normally trigger an ABI number increase and this
bug would be RC.

However, this package is only used by a single set of related packages
(Postbooks packages), so I've simply marked the bug important and
ensured that the reverse dependencies explicitly require v3.3.10.  This
is not fool proof but it will ensure people jumping from the version in
stable to the version in testing or backports won't be impacted.

Going forward, we need to pursue one of the following strategies:

a) upstream to increment the ABI number when required and try to avoid
making changes that break ABI when fixing issues in the stable version

b) use the release number in the SONAME.  An example of a package doing
things this way is reSIProcate (e.g. for v1.9.x, SONAME ==
libresip-1.9), upstream has committed to use changes in major or minor
version numbers when ABI changes occur.

In both cases, the binary package name has to be renamed when upstream
makes a new ABI number or when upstream changes the major or minor
release number.

Another factor to consider: this package contains multiple library
files, maybe each should be split into a separate binary package?


Note the ABI number has always been 1 and the SONAME is libMetaSQL.so.1

$ objdump -p /usr/lib/x86_64-linux-gnu/libMetaSQL.so | grep SONAME
  SONAME               libMetaSQL.so.1



Useful references:

https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html



More information about the pkg-xtuple-maintainers mailing list