Hi Joachim,
This is more than a cruft-checker issue: the missing symlink breaks
services on a fresh install.
Because libpicohttpparser1 ships only libpicohttpparser.so.1.2, the
libpicohttpparser.so.1 symlink does not exist until the libc-bin
ldconfig trigger runs at the end of the dpkg run. Until then, nothing
linked against it can be loaded. libmosquitto1 links against it, so a
package that uses libmosquitto1 and starts a service from its postinst
fails. I hit this with shairport-sync in Salsa CI:
Setting up libpicohttpparser1:amd64 (1.2+ds-2) ...
Setting up shairport-sync (5.6.2-2+salsaci+20261108+3) ...
Processing triggers for libc-bin (2.43-7) ...
shairport-sync[4032]: /usr/bin/shairport-sync: error while loading
shared libraries: libpicohttpparser.so.1: cannot open shared object
file: No such file or directory
systemd[1]: shairport-sync.service: Main process exited, code=exited,
status=127/n/a
Full log: https://salsa.debian.org/debian/shairport-sync/-/jobs/10615314
shairport-sync recovers because its unit restarts on failure. A service
without a restart policy would stay failed, and the mosquitto broker may
be affected in the same way.
This is the situation Debian Policy 8.1 describes:
The run-time library package should include the symbolic link for the
SONAME that ldconfig would create for the shared libraries. [...] This
is needed so that the dynamic linker (for example ld.so or
ld-linux.so.*) can find the library between the time that dpkg
installs it and the time that ldconfig is run in the postinst script.
See:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
The ldconfig trigger is still needed to refresh the cache, but it does
not replace shipping the symlink. Alexandre's patch from 4 November,
which creates the symlink so the existing install glob picks it up,
would fix this. Please also drop the
lacks-versioned-link-to-shared-library lintian override.
Cheers,
Chris
--
Chris Boot
[email protected]
