Ok, I tried a different diff[1], and got:
obj-x86_64-linux-gnu/src/libcbor.so
obj-x86_64-linux-gnu/src/libcbor.so.0.6.0
obj-x86_64-linux-gnu/src/libcbor.so.6
So question for the MIR team:
a) stick to upstream, with SONAME being libcbor.so.0.6.0 (full version, meaning a minor version update will require rdepends to be rebuilt)
b) like (a), but also change the binary package name from libcbor0 to libcbor0.6.0 (meaning NEW package every time this updates)
c) patch like above, making up a soname of our own (RISKY). Would still require a package rename, since we wouldn't be using libcbor.so.0 which was used in 0.5.0 which is in focal currently. Although dpkg-gensymbols would take care of adjusting the dependency I guess.
I'm inclined towards (b) as more correct than (a), and (c) only if upstream agrees to it and makes a new release with that change.
Ok, I tried a different diff[1], and got: 64-linux- gnu/src/ libcbor. so 64-linux- gnu/src/ libcbor. so.0.6. 0 64-linux- gnu/src/ libcbor. so.6
obj-x86_
obj-x86_
obj-x86_
With: 64-linux- gnu/src/ libcbor. so.0.6. 0 | grep SONAME
$ objdump -x obj-x86_
SONAME libcbor.so.6
("6" was made up by me).
So question for the MIR team:
a) stick to upstream, with SONAME being libcbor.so.0.6.0 (full version, meaning a minor version update will require rdepends to be rebuilt)
b) like (a), but also change the binary package name from libcbor0 to libcbor0.6.0 (meaning NEW package every time this updates)
c) patch like above, making up a soname of our own (RISKY). Would still require a package rename, since we wouldn't be using libcbor.so.0 which was used in 0.5.0 which is in focal currently. Although dpkg-gensymbols would take care of adjusting the dependency I guess.
I'm inclined towards (b) as more correct than (a), and (c) only if upstream agrees to it and makes a new release with that change.
1. https:/ /github. com/PJK/ libcbor/ issues/ 52#issuecomment -601913358