https://bugzilla.redhat.com/show_bug.cgi?id=2313784
--- Comment #18 from Ben Beasley code@musicinmybrain.net --- (In reply to Fabio Valentini from comment #17)
Thanks Ben for the additional feedback - latest version of the package looks good to me, with one minor exception that might need a clarification:
[?]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path.
This is due to "libjiter_python.so()(64bit)".
I looked at other Python packages that provide native modules, and none of them had RPM provides for their native .so modules - with one exception that I could find, pydantic-core. I'm not sure what the difference is between these two and other "native" Python extension modules, and if RPM should be prevented from generating Provides for this .so file.
After quite a bit of group investigation in the Fedora Python Matrix channel, we’ve concluded that this changed in Rust 1.81, and Fabio filed bug 2314879.
I recommend adding the following workaround:
# The Python extension module now gets a SONAME of libjiter_python.so; we # must ensure it is not used to generate automatic Provides. See: # Rust 1.81+ implicitly / automatically sets soname on cdylib targets # https://bugzilla.redhat.com/show_bug.cgi?id=2314879 # https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndReq... %global __provides_exclude ^lib_jiter_python\.so.*$
I’m working on adding similar workarounds to other Rust-based Python extensions, which will all be affected once they are rebuilt with Rust 1.81.