On Mon, Apr 22, 2019 at 06:14:15PM +0200, Miro Hrončok wrote: > On 18. 04. 19 18:17, Richard Shaw wrote: > >I'm working on packaging PySide2 for Fedora[1] and have a couple of questions... > > > >*** Also, I could use an experienced python packager to do the review! *** > > > >1. Should the %python_provide macro be applied to > >python-<pkgname>-devel packages? Or just for the main python > >module package? > > Everything that is called python2-foo or python3-foo should be > accompanied by %python_provide. it doesn't matter whether it is > "main python module package" or not. > > If the package is called python-<pkgname>-devel (sometimes happens > if it is Python version agnostic) -> no need for %python_provide. > > If the package is called python3-<pkgname>-devel, %python_provide should be used. > > >2. Do I need to filter requires/provides for C python libraries if > >their not private? > > I always understand it that provided libxxx.so.so.X.Y() are intended > to be used by linkers directly. E.g. Python modules should not > provide libxxx.cpython-37m-x86_64-linux-gnu.so or similar. tl;dr: the Provides in question is harmless and/or correct and should be left in. The problem seems to be caused by the location of the module: > /usr/lib64/libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12 which leads to Provides: libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12()(64bit). IIUC, the module is compiled using the python stable ABI (PEP 384). Normally, cpython modules live under a python-version-specific directory (e.g. /usr/lib64/python3.8/site-packages/). But with the stable ABI, no version-specific directory is appropriate, and thus the library was put in the general library location. This means that the default rpm filters to ignore cpython modules don't work. The module that is loaded from python is at /usr/lib64/python3.7/site-packages/shiboken2/shiboken2.cpython-37m-x86_64-linux-gnu.so, and it links to /usr/lib64/libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12. I assume this split is done to share the code. The binary in /usr/lib64 is 270k, and the one in site-packages is 20k. I think this split and using /usr/lib64 is a reasonable solution. It could even be argued that the Provides is correct. Despite the strange name, the module in /usr/lib64 is a shared library that could be used (linked to) by multiple python-version-specific modules. Also, because of the "cpython-37m-x86_64-linux-gnu" tag there is no possibility to mistake this for any normal library. (That said, we are unlikely to make any use of this split in Fedora. We generally have just one version of python3, and further packaging work would be needed to make the whole thing work anyway. But I don't see any reason to deviate from upstream and remove the split.) Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
