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

[Michael Banck]

Hello Filippo,

On Mon, Nov 01, 2010 at 11:17:06AM +0100, Filippo Rusconi wrote:
> On Sun, Oct 31, 2010 at 12:37:01PM +0100, Michael Banck wrote:
> > > 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 the expected standard behaviour when running the upstream setup.py
at least.  I am not a specialist on python modules, though. One thing to
consider is that the module's name ("calculations.so" I think) is quite
generic.

It is not quite clear to me at this point what upstream intended, but
maybe you can convince them to rename it to "mmass_calculations.so" or
so.  That would avoid possibly conflicting with other python modules.
As it is imported at one place only I think, renaming this might be
feasable for the current package without having to wait for a new
upstream release, but getting feedback from upstream first would be
valuable.
 
Maybe a hybrid approach would be useful: Install the python module via
setup.py, but install it to /usr/lib/mmass/mspy/plot in the
mmass.install file.

In the end, I think either way of doing it is OK.

> > 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' ?

Hrm, I did not know there was such a lintian warning.  Certainly the
majority of the package will be Arch: all, but we are talking about (if
I remember correctly) a couple of megabytes here, not dozens of
megabytes.  And every new package also carries some wait as every user's
package database grows by one entry.

So personally I think either ignoring or overriding the lintian warning
would be fine.


Cheers,

Michael