On Thu, 11 Dec 2014 14:23:12 +0000, Paul Howarth wrote: > The python packaging guidelines include a pointer to > http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Arch-specific_extensions_to_scripting_languages, > which includes an example for python packages to avoid provides for > arch-specific shared objects in the sitearch hierarchy. > > I was doing a local build of limxml2 and added filtering for the > libxml2mod.so object in the libxml2-python sub-package. However, when I > came to update to my local build I ran into a dependency issue because > python-dmidecode actually requires libxml2mod.so (and libxml2-python is > the only thing that currently provides it). > > I don't know the specifics of the relationship between python-dmidecode > and libxml2-python, That would be the interesting bit, though. Right now, the shared lib dependency in dmidecodemod.so doesn't work out-of-the-box, because the runtime linker won't find it: $ ldd /usr/lib64/python2.7/site-packages/dmidecodemod.so|grep fo libxml2mod.so => not found You also cannot import this .so in Python directly for the same reason, >>> import dmidecodemod Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: libxml2mod.so: cannot open shared object file: No such file or directory but only if importing libxml2 beforehand, >>> import libxml2 >>> import dmidecodemod >>> and that is because libxml2 Python module does import libxml2mod in the very first line. Digging a little bit further, python-dmidecode links with -lxml2mod explicitly without using an official API header for it: # this library is not reported and we need it anyway libs.append('xml2mod') libxml_wrap.h, which is uses for accessing a private interface, tells * This include file is taken from the libxml2 source tree, to provide the needed * declarations to implement usage of libxml2xml.so which is a hack that leads to this dependency. > so I'd like to ask: > > 1. Is it *always* right to filter provides for private shared objects, It is right for the ordinary case when the shared lib is stored outside runtime linker's search path. > or are exceptions like this quite common, Doubtful. It looks like a special case due to the inter-dependency added by using a copied header. You simply cannot load (= "import") this .so without preloading the _missing_ lib, because runtime linker cannot find it. > or > > 2. If this is not a real dependency, what should packages like > python-dmidecode do to avoid them? It could filter out the auto-Requires on libxml2mod.so. > Is it due to unnecessary linking perhaps? It doesn't look like that. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
