[Debichem-devel] call form supervision of the packaging of a python software

[Michael Banck]

Hi Filippo,

On Sat, Oct 30, 2010 at 10:46:56PM +0200, Filippo Rusconi wrote:
> I package a mass spectrometry software called mmass. This software now
> ships a private module as a share object that gets build from C code.
> 
> It is the first time I package a python package that ships a private
> binary module. Would any person listening be kind enough to give a
> whirl at the packging ?

Sure, there are a couple of other Debichem packages which have this,
like pymol and the OpenBabel python bindings.
 
> In particular, one tricky part is the fact that the private module is
> build in a created directory that has a different name each time the
> platform changes. So I had to use '*' wildcards during the moving of
> the files into the package. On my 386-compatible intel computer the
> package works fine, but I wonder if any amd64 user would experience
> problems.
 
You build the module via setup.py.  You can also install it that way,
like:

install:
	cd mspy/plot && python2.6 setup.py install --prefix=/usr
--root=$(CURDIR)/debian/tmp

This will install the C module under /usr/lib/python2.6/site-packages,
the usual (for such modules) location.  Mmass will find it fine as I
just tested.

It is weird that the setup.py does not install the other python files as
well, I think "setup.py install" should install the whole mmass package
(not just the C module), so improving it might be welcome by upstream
(but is not needed for an upload now).

I think it would be easier to not have a new mmass-modules package, but
rather just make the mmass package Arch: any and ship the python module
in there.  The other advantage is that NEW packages are processed very
slowly right now (it's release time), so not introducing a new package
will make mmass-3.8.0 available to our users immediately.

Finally, if you introduce an install target as proposed above (and let
the binary targets depend on it), the dh_prep from the binary-* targets
should be moved there, as it wipes out debian/tmp and thus the "setup.py
install" line above will get reverted. 


Michael