[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


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: