Package: dh-python Version: 6.20240603 Severity: normal I have a library package (scipy) which builds a shared library (libsf_error_state.so)) used by the python code. This is a standard .so shared library, not a python extension, so it shouldn't be renamed with magic tags nor multiarch tuples. Otherwise the python code doesn't know the name of the shared library to access.
So I specify the file to exclude when running dh_python3 dh_python3 --exclude=libsf_error_state.so But the exclude option gets ignored, the shared library is renamed anyway: $ dh_python3 --exclude=libsf_error_state.so I: dh_python3 fs:418: renaming libsf_error_state.so to libsf_error_state.cpython-312-x86_64-linux-gnu.so Then the package fails to work at runtime: ImportError: libsf_error_state.so: cannot open shared object file: No such file or directory So the --exclude option is not working. For more context, the shared library in question is new in scipy 1.14, added to scipy/special. This is the first time scipy has provided a shared library (distinct from python extensions), added in PR#20321 https://github.com/scipy/scipy/pull/20321 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-python depends on: ii python3 3.12.5-1 ii python3-setuptools 73.0.1-1 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.22.11 ii flit 3.9.0-2 ii libdpkg-perl 1.22.11 ii python3-build 1.2.1-1 ii python3-installer 0.7.0+dfsg1-3 ii python3-wheel 0.44.0-1 -- no debconf information
