Re: Second round of advise on packaging python-csb
On 13/11/12 21:17, Jakub Wilk wrote:
> * 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.
Makes sense. Done.
>> * Added dependency on ${python:Depends}
>
> You could also remove ${shlib:Depends}, as the package doesn't ship any
> ELF executables or shared libraries.
Gone it is.
>> * 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.
Right, things get a bit blurry for me here. When upstream releases a new
version, they take a snapshot from their repository and build the
release tarball. This process includes the creation of the docs from
source. The tarball I use for the package, therefore, has the already
cooked HTML files, and I happily committed them to the repository.
Seeing as it's 24M of HTML files, it would most likely be a different
package. However, I assume from your comment about rebuilding from
source that it would not be as easy as taking the "docs" dir and
packaging it separately?
>> 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...
Another blurry point. I'm having a hard time understanding the
separation of tasks between the tarball packaging done by upstream I
described before, and my Debian packaging. Similar to the docs, the
tests are run by upstream when they build the tarball. Is it common to
also include these tests in Debian packages?
Thanks a lot for your patience, I do realize these are quite basic
questions.
Reply to: