Re: [Fedora-packaging] Provides for python shared objects
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#...,
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.