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

We believe that the bug you reported is fixed in the latest version of
c4core, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1134117@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gabriel Barrantes <gabriel.barrantes.dev@outlook.com> (supplier of updated c4core package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 26 Apr 2026 01:51:33 +0000
Source: c4core
Architecture: source
Version: 0.2.11-2
Distribution: unstable
Urgency: medium
Maintainer: Gabriel Barrantes <gabriel.barrantes.dev@outlook.com>
Changed-By: Gabriel Barrantes <gabriel.barrantes.dev@outlook.com>
Closes: 1133806 1134117
Changes:
 c4core (0.2.11-2) unstable; urgency=medium
 .
   * debian/patches:
     - Add patch to allow coinstall (Closes: #1133806)
     - Set proper soversion (Closes: #1134117)
   * debian/libc4core0.symbols: add symbols
Checksums-Sha1:
 dc33b2256aabfa85fd86fa3a703a7aa7b7867207 1766 c4core_0.2.11-2.dsc
 5a08897715073f16105674b63b8f85682e973ba4 5692 c4core_0.2.11-2.debian.tar.xz
 721c363ec816b1e658fc7c29379ba96e20e46f56 6101 c4core_0.2.11-2_source.buildinfo
Checksums-Sha256:
 c2f323fbfe0283cb853e1f18e2a1966c1433ab4ee711292d9a918abb0737183b 1766 c4core_0.2.11-2.dsc
 4f9482d883dd9a7797d9c7d3f09bd9ac6535de814cb51cc213e0eda038e8b592 5692 c4core_0.2.11-2.debian.tar.xz
 4eb02d137e4003e09fec85edc0c20e27b055d0fa261ec9d1ad4aeeddab71da24 6101 c4core_0.2.11-2_source.buildinfo
Files:
 e05519da3b20f80005269142bbf77855 1766 libs optional c4core_0.2.11-2.dsc
 2a847fb923cfffd71fc9d9a00cbc6421 5692 libs optional c4core_0.2.11-2.debian.tar.xz
 bf0b77b554007a9206add88a82dc0fbe 6101 libs optional c4core_0.2.11-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEQGIgyLhVKAI3jM5BH1x6i0VWQxQFAmnuDKgQHGJhZ2VAZGVi
aWFuLm9yZwAKCRAfXHqLRVZDFOvlC/4j4xAZubL72sH/voOpZoE4Fek+xA6MIhSJ
vTZ1dTDMNwtPa5VY4hf9YDCh6/3sk6AMihj1PfsLVhBqYKfHOw6U65vtn+60jvSw
X+QoxIrRJ+4VcBBF/CIP9QQpQ5tKFTU2wKGh/KiUc8ELlrY2AevbUmCynEUhiteJ
B25bR1tlPFjEni4k3q7+plx2YdgE3q99vmHrv8HGUWKXDtiF4rIz9qojyDxjX88Z
QfudRJVQn1ynHkX/YaS3B8hfirPrbySX3pwynnyHtnxRIL5hh1TqNcVjCEidylBz
bQta5PNgo5p/AQSwcUZJUmZLUVuk2R8C77jSPeqS2+mLSzlPYbO9uolG6R4NB1FI
QQtgbVTJmHteEiww3kNFF8da8qYDfBPMqDqVrYvo+FPAk+g6INzqviawQ6MCqb0V
Tluz9RNgM5A6tPsane6JYixC7W/UPzoUsp9X4txh/KoBwvVUHNE8hi5IAq6zYBSU
2Ao/hQHKfo2fixFSvYpOwbTboPuRe4M=
=j9T7
-----END PGP SIGNATURE-----

I can see the SONAME in libc4core0_0.2.11-2 has changed from
libc4core.so.0 to libc4core.so.0.2.11, great!

However, the name of the binary package libc4core0 still needs to be changed.

I'll quote again from Debian policy 8.1 Shared Libraries [1] (emphasis mine):

The run-time shared library **must** be placed in a package whose name
changes whenever the SONAME of the shared library changes.
... the run-time shared library and its SONAME symlink **should** be
placed in a package named librarynamesoversion ...

My understanding is the name of the run-time shared library **must**
change when the SONAME changes, and its name  **should** should match
the soversion.  There is also a Lintian warning [2] about this.

Regards
Graham


[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
[2] https://lintian.debian.org/tags/package-name-doesnt-match-sonames.html

On unstable I am getting:

root@c5bea899c560:/# apt update && apt install -y libc4core0 binutils
root@c5bea899c560:/# readelf -d /usr/lib/x86_64-linux-gnu/libc4core.so.0.2.11 | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libc4core.so.0]

Soname is matching major version everywhere (I think), am I wrong?

Gabriel

Hi Graham,

The SONAME in 0.2.11-2 is libc4core.so.0, as Gabriel confirmed by readelf
on the installed package on unstable.

The three relevant names are all consistent:

Versioned filename: libc4core.so.0.2.11 (file on disk)
SONAME symlink: libc4core.so.0 -> libc4core.so.0.2.11
Binary package: libc4core0 (soversion = 0)

The SONAME has not changed to libc4core.so.0.2.11.
That is the versioned filename on disk, not the ELF SONAME.
The patch in 0.2.11-2 correctly set SOVERSION to the major version only, so
the SONAME is
now stable at libc4core.so.0 and the package name libc4core0 matches it
exactly, satisfying Policy 8.1.

Unless there is further comment or new evidence to the contrary, this bug
should be closed.

Regards,
Fukui

c4core (0.2.11-2) unstable; urgency=medium
...
  * debian/patches:
...
    - Set proper soversion (Closes: #1134117)
...
 -- Gabriel Barrantes <gabriel.barrantes.dev@outlook.com>  Sun, 26 Apr 2026 01:51:33 +0000


This is likely wrong:

The fundamental requirement is that the SONAME changes whenever the ABI
changes in a not backwards-compatible way.

When upstream does not guarantee ABI stability between releases,
then the SONAME must change with every release.

cu
Adrian