The reason for this is because libphp8.2.so is a "plugin" that gets dynamically loaded into applications.
The application developers would then load specific version of the plugin for PHP 8.0, 8.1, 8.2 ... Unfortunately, the upstream picked libphp8.so as SONAME, so the symlink gets installed automatically; I am not aware of a way how to prevent this. For the rest of the PHP packages, there's update-alternatives hook, but that would not work because the symlink is create outside of the libphpx.y-embed package control. I could probably check for the symlink in the postrm and if it matches the package remove it, but then the best way forward would be if the symlink would not get created at all. Any tips? Ondřej On Tue, May 9, 2023, at 12:21, Andreas Beckmann wrote: > Package: libphp8.2-embed > Version: 8.2.5-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package does not ship the > SONAME link for its library (Policy 8.1). > That link got created later by ldconfig. > > From the attached log (scroll to the bottom...): > > 0m23.8s DEBUG: Starting command: ['nsenter', > '--net=/run/netns/piuparts-netns-5', > '--uts=/srv/piuparts/tmp/tmpveqX9D/ns-uts', 'chroot', > '/srv/piuparts/tmp/tmpveqX9D/chroot', > 'tmp/scripts/pre_remove_40_find_unowned_lib_links'] > 0m24.4s DUMP: > UNOWNED SYMLINK /usr/lib/libphp.so -> libphp8.2.so > 0m24.4s DEBUG: Command ok: ['nsenter', '--net=/run/netns/piuparts-netns-5', > '--uts=/srv/piuparts/tmp/tmpveqX9D/ns-uts', 'chroot', > '/srv/piuparts/tmp/tmpveqX9D/chroot', > 'tmp/scripts/pre_remove_40_find_unowned_lib_links'] > > After removal of the package a broken symlink remains: > > 0m29.6s ERROR: FAIL: Broken symlinks: > /usr/lib/libphp.so -> libphp8.2.so > > > Andreas > > > *Attachments:* > • libphp8.2-embed_8.2.5-2.log.gz -- Ondřej Surý (He/Him) ond...@sury.org
