[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: phing (Another try...)

Hash: SHA1

Hi Nicolas,

IANADD (twb told me, I shall be lazy!), here are some comments on your

 On 21.07.2011 09:13, Nicolas wrote:
> I am looking for a sponsor for my package "phing".

* Please extend description of the -doc package. Its a bit too short.
You don't need to be too verbose, but please expand it by a few words.
For example you could tell what exactly the package contains and what
its purpose is. Compare with other -doc packages in Debian to get an idea

* Your copyright looks pretty good, however "Copyright: 2001,2002
THYRELL" is probably a bit to few of information. Maybe add a contact
address, I noticed in the code is listed one. Same for "2003,
seasonfive". Yes, this is pure pedantry - feel free to ignore this.

* There is a new upstream release. Please consider packaging it.
Besides, the checksums of your orig.tar.gz don't not match with
upstream's package, being it the full package or the PEAR one. Please
don't touch it.

$ sha1sum phing-2.4.5.tgz.1
bf4c5e709c9141555c299e02aab8ac80cddd2cf7  phing-2.4.5.tgz.1 (this is PEAR)
$ sha1sum phing-2.4.5.tgz
f3e2eb295317b79a9e4223c193430a2896883967  phing-2.4.5.tgz
$ sha1sum phing_2.4.5.orig.tar.gz
367c6a92bee3d3c73c6b36c9afa35a122c1eb11c  phing_2.4.5.orig.tar.gz

* What's /usr/share/php/phing/etc for? Those files don't look like
something which should be put in a etc-directory. I'm fine if you keep
it that way in /usr/share/php/phing/etc, I'm just trying to find out,
whether those files are meant to be touched at all. If so, they
shouldn't reside in /usr.

* In debian/rules, please remove unneeded comments dh-make produced.

* Please generate your manpage during build. It seems to me, you ship it
pre-compiled from the SGML man page you wrote.

* Similar case for the API docs you package straight from the tarball.
The DFSG mandate that a software package is available from source and
its processing must be self-containing (e.g. compare with the "preferred
form for modification" from the GPL license). For the generated API docs
this means, there must be a way to regenerate those docs by means the
main archive provides. You don't necessarily need to do this when
producing the binary package, but please add at least a README.source
file, where you document how to regenerate those API docs, upstream
ships, if desired.

* Your upstream tarball contains regression tests. Consider running them
during build.

Good work. Those are almost all cosmetic changes.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: