Re: changes in python packaging
* Steve Langasek <vorlon@debian.org>, 2013-09-15, 13:54:
I'm having problems with one of my packages that includes a python module.
The package is vips. I am not a python person, so this may be simple.
The last time I built the package, there were several module binary files
that got installed appropriately. For example:
% dpkg --listfiles python-vipscc| grep vmaskmodule.a
/usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a
/usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a
Well, to start off, this doesn't look correct at all. Python modules are
never .a files; these appear to be spurious static builds of the modules
because you're using a non-pythonic build system that assumes it's appropriate
to build both shared and static versions of "libraries". But these are not
libraries, they're DSOs; you should not ship these .a files in your package.
ACK
You might want to try out lintian4python, which emits:
w: python-vipscc: static-extension usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a
w: python-vipscc: static-extension usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a
Now when I rebuild the package with no changes at all, I get something like
this:
% dpkg --contents python-vipscc_7.34.2-1_amd64.deb| grep vmaskmodule.a
-rw-r--r-- root/root 1127858 2013-09-15 09:33 ./usr/share/pyshared/vipsCC/vmaskmodule.a
lrwxrwxrwx root/root 0 2013-09-15 09:33 ./usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a -> ../../../../share/pyshared/vipsCC/vmaskmodule.a
Okay, this example shows a newer version of the package, but when I rebuild
the exact same version as before, I get the same result.
This looks like a change in the python helpers, yes, probably to handle
moving/symlinking of files other than .py or .so that some python modules
include and expect to be present in their directory. So this is a change from
whitelist handling of files with a .py extension, to blacklist handling of
files with a .so extension.
My understanding is that .a files used to be kept in /usr/lib because their
contents varied with Python versions, so they couldn't be shared. Now that only
one version of Python is supported, there's nothing to keep them there...
The .a files are ending up in the "wrong" place because dh_python isn't
treating them specially... because they're not special for python, they're
extraneous files to be deleted.
...because they're indeed not special-cased.
--
Jakub Wilk
Reply to: