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

For the record, scipy PR#20321 is applied as commit 55849f7

https://github.com/scipy/scipy/commit/55849f7b9fe6bd7326e4447d05f3a5c40e76aa83

Hi Drew (2024.08.23_21:51:41_+0000)

Currently -X only applies to byte-compilation. The only way to do what
you want is --no-ext-rename, but that's all or nothing.

I think we can extend -X to apply to C extensions too...

I could also imagine doing some magic to detect symbols in a shared
library that look like a Python C extension, but... let's not go that
far.

Stefano

Hi Drew (2024.08.24_11:39:04_+0000)
You'd be fine with --no-ext-rename.

Your build system is already fully qualifying the C extension filenames.

If it didn't: Once you have any .so file in a non-multiarch path, you
can't be Multi-Arch: same. So there would be no benefit in including the
multiarch tag.

I pushed a git branch with a patch that adds this feature
(exclude_ext_rename), as I've already written it. But I don't think it's
a feature we need. So I don't intend to merge it.

Stefano

Hello,

Bug #1079496 in dh-python reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/tools/dh-python/-/commit/fe6d2d4874e0c60f4286b3db328c4bd697972aa3
------------------------------------------------------------------------
dh_python3: Add --exclude-ext-rename=REGEX to allow Python Extensions to be renamed while skipping plugins. (Closes: #1079496)
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1079496

I see what you mean.  It must be a feature of the way the mesonpy build
systen invokes cython. It's already building
scipy/special/cython_special.so, for instance, as
scipy/special/cython_special.cpython-312-x86_64-linux-gnu.so

I can try your recommendation to just use dh_python3 with
--no-ext-rename in a next scipy upload.

Actually I already had to drop Multi-Arch from scipy, since it embeds
the arch in some plain text files (e.g. __config__.py).  But that's a
different issue (Bug#1078977).

Fair enough for scipy.  Across the broader python ecosystem it might be
question of whether any other package might want to include shared
libraries in the python package tree distinct from python extensions.

Hi Drew (2024.08.24_14:56:07_+0000)

Many already do, and use --no-ext-rename.

They have to live with not being multi-arch compatible.

Stefano