Hi Maintainer

As per Debian policy 8.1 Shared Libraries [1]:

The run-time shared library must be placed in a package whose name
changes whenever the SONAME of the shared library changes.

This was not done in the 0.2.11-1 upload (and also not in the 0.2.7-1 upload).

The effect can be seen in the autopkgtest regression of jsonnet in
testing [2].  I have copied part of the log below.

Regards
Graham


[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
[2] https://ci.debian.net/packages/j/jsonnet/testing/amd64/


 32s autopkgtest [09:44:27]: test command1: DISABLE_LIB_TESTS=1
JSONNET_BIN=/usr/bin/jsonnet JSONNETFMT_BIN=/usr/bin/jsonnetfmt sh
tests.sh
 32s autopkgtest [09:44:27]: test command1: [-----------------------
 32s snippet: /usr/bin/jsonnet: error while loading shared libraries:
libc4core.so.0.2.7: cannot open shared object file: No such file or
directory
 32s  [31;1mFAIL [0m  [1m(exit code) [0m:  [36m/usr/bin/jsonnet
--ext-str prefix='Happy Hour ' --ext-code brunch=true --tla-str
prefix='Happy Hour ' --tla-code brunch=true .//arith.jsonnet [0m
 32s This run's output:
 32s /usr/bin/jsonnet: error while loading shared libraries:
libc4core.so.0.2.7: cannot open shared object file: No such file or
directory
 32s Actual exit code 127, expected 0

Hi Graham,

The situation with rapidyaml mirrors c4core exactly.
The package name `libryml0` is correct per Debian Policy 8.1 — it must
track the embedded ELF SONAME (`libryml.so.0`), not the full versioned
filename on disk.
A CMake patch setting `SOVERSION` to the major version (as done in
Gabriel's MR [0]) ensures a stable SONAME while allowing the on-disk
library to be `libryml.so.0.11.1`.
This keeps everything consistent without unnecessary transitions:

* Versioned filename: libryml.so.0.11.1
* SONAME symlink: libryml.so.0 => libryml.so.0.11.1
* Binary package: libryml0

Renaming the runtime package on every upstream release (e.g. to
`libryml0.11.1`) would technically satisfy the policy but would create
excessive churn during the 0.x series, even when there is no ABI
break.

This bug should be closed unless new evidence of an actual SONAME
change emerges.

[0] https://salsa.debian.org/debian/rapidyaml/-/merge_requests/1

Regards,
Fukui

This is not true.

The ELF SONAME of libryml is:

$ objdump -p /usr/lib/x86_64-linux-gnu/libryml.so.0.10.0 | grep SONAME
  SONAME               libryml.so.0.10.0
$

cu
Adrian

Adrian,

[0] https://salsa.debian.org/debian/rapidyaml/-/merge_requests/1

to properly have it fix on version 0.11.1-1.

root@e17657d36880:~/rapidyaml# dpkg -s libryml0 | grep Version
Version: 0.11.1+ds-1
root@e17657d36880:~/rapidyaml# readelf -d /usr/lib/x86_64-linux-gnu/libryml.so.0.11.1 | grep SONAME
0x000000000000000e (SONAME)             Library soname: [libryml.so.0]
root@e17657d36880:~/rapidyaml#

Daichi, thanks a lot for following a long this issue.

Gabriel

Does upstream guarantee ABI stability between releases?

If upstream does not make such guarantees, then the upstream soname is
correct and there has to be a library transition for every new upstream
version.

cu
Adrian