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

[Filippo Rusconi]

Hello Michael,

thank you very much for you documented reply.

On Sun, Oct 31, 2010 at 12:37:01PM +0100, Michael Banck wrote:

> > 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.
>  
I'll study these packages to learn new stuff.

> > 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.

Great ! I find in this subject that the opinions vary. I was told that
since the upstream package ships the module as a private one (nobody
else will use it), I could ship it like I initially planned. If the
expected standard behaviour is to put that module in
/usr/lib/python2.6/site-packages, then I'll gladly make the jump to
that new way of doing.

 
> 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).

As you noted in another message, there is that setup.py file, but with
no GNU/Linux-specific stance. I was planning to make my way through
writing one. However, I wanted to go straight to a new package
version.

> 
> 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.

Right, I understand this reasoning. In fact this is precisely what I
did initially :-) However, lintian would send a nasty message
indicating that there are massive amount of 'all' stuff in the package
for a little amount of 'any' material. Then I got a stance on the fact
that all this mess would impose a weight on the debian infrastructure
and so on. So I finally decided to comply with
Prof. Lintian... However, I find the argument about NEW really
compelling, at least for the moment. 

The point is : should I override Lintian's message ? Will my package be
rejected because of having only 'any' material, while in fact the vast
majority of it is 'all' ?

> 
> 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. 

I'll try to implement this and then tell you of the new version.

Thank you again,

Best regards,
                 Filippo

-- 
Filippo Rusconi, PhD - CNRS - public key C78F687C
Author of ``massXpert''     at http://www.massxpert.org