Re: Second round of advise on packaging python-csb
* Tomás Di Domenico <tdido@tdido.com.ar>, 2012-11-12, 15:34:
* Rebuilt the package with an upstream release tarball
Much better now. :)
* Changed debian/* license to MIT, matching upstream's
DEP-5-compliant short license name for the MIT license is "Expat".
You don't have to repeat the license text twice; you could use a
stand-alone license paragraph.
* Added dependency on ${python:Depends}
You could also remove ${shlib:Depends}, as the package doesn't ship any
ELF executables or shared libraries.
* Removed the empty docs file
Speaking of docs, the upstream tarball contains HTML-formatted
documentation for the module's API. How would this be handled?
Ideally, the documentation should be rebuilt from source.
Should it be made available as a separate package?
If the documentation is big, then putting it into a separate package is
a good idea.
Speaking of big things, the binary package is 3.8M. It looks like most
of it is the test suite. Does it make sense to include it in the binary
package?
Tests however _love_ to be run at build time! :) You might also want to
provide DEP-8 tests. (See below however.)
csb/test/data/*.pickle appear to contain pickled Python objects. Do you
know how it was created? Or in other words, where is the source for it?
Note that unpickling (which is what the test suite appears be doing)
untrusted stuff can result in execution of arbitrary code...
--
Jakub Wilk
Reply to: