[php-maint] Packaging PHP_CodeCoverage and others from phpunit.de (needed by phpunit 3.5)
zigo at debian.org
Thu Feb 3 06:30:58 UTC 2011
On 02/03/2011 02:43 AM, Luis Uribe wrote:
> Regarding the other packages, they are "small" but don't know if you
> have the time to review it. Or do you think it's better to ask for a
> revision on php-pkg-maint@?
I may have time (I usually do for small PHP pear packages), but it's
always better to do such a request publicly, on both
debian-mentors at lists.d.o and the PKG-php list, even if you address to me
directly. In Debian, we love things to be open and public, and I begin
to like that way as well (it took me some time, but now I do). Others
might pick-up some issues, see what I write and correct me if I'm wrong
(DDs aren't god and don't know everything), etc.
zigo at GPLHost:buzzig>_ ~/sources/debian_sponsoring/pkg-php/php-timer$
lintian -Ii php-timer_1.0.0-1_amd64.changes
I: php-timer: extended-description-is-probably-too-short
N: The extended description (the lines after the first line of the
N: "Description:" field) is only one or two lines long. The extended
N: description should provide a user with enough information to decide
N: whether they want to install this package, what it contains, and how it
N: compares to similar packages. One or two lines is normally not enough to
N: do this.
N: Refer to Debian Developer's Reference section 6.2.1 (General guidelines
N: for package descriptions) and Debian Developer's Reference section 6.2.3
N: (The long description) for details.
N: Severity: minor, Certainty: possible
Please run lintian with the -Ii flag before asking for a review, you
could have easily avoid that one. I also think that your long desc is
too short when I read it.
Then your package is using CDBS. I don't do CDBS things, so I wont be
able to review it. If you want my help, then switch to debhelper. You
may have a look to few of my PHP packages if you are searching for examples:
Even though I will always refuse to sponsor packages using CDBS, I can
tell few things here. Your package has a debian/dirs file having:
"usr/share/php" in it, yet there's "PHP_Timer-*/PHP usr/share/php" in
the debian/install. That leads me to say that your debian/dirs is
useless. Maybe that's because you used dh-make-php (which I would advise
to not use if possible, as this is the kind of jokes it's doing). In
fact, I wrote my own tool called "pear2deb", which does the same kind of
thing, but using debhelper :) I may release it one day...
In your debian/control, you wrote:
The Vcs-Git thing is *not* the upstream Git, but the one used by *you*
for your Debian packaging work. In fact, I did the same mistake, so I
understand why you did it. Here's am example from my xen-qemu-dm package:
You may want to setup a new account on Alioth for that (maybe
uribe-guest), and do your Debian packaging using Git. In fact, best
would be to host that in the pkg-xen archive directly (in /git/pkg-php),
but you wont have the write rights if you don't join the pkg-php team.
If you have a bunch of PHP packages to do, then it might be a good idea
to join the project!
Also, I would suggest you to use the machine parseable format for your
debian/copyright file. It isn't a requirement of Debian, but it is one
of mine for sponsoring. Debian is slowly adopting it, and I want to
vouch for it by forcing my sponsorees to use it. I think it is a lot
more easy to read than the mess we currently have in Debian.
My own packages only need to have the top header be re-written, the core
of my copyright files are already using that format the top header has
been a moving target for years, while the body of the files almost never
changed, so I only used the formatting for the body of the
debian/copyright. If you want to only edit the body of the copyright
file using this format, it's fine for me (this is still what I do, until
the "candidate" thing is adopted by all, also, I don't like the current
header format which lacks a "free of use" part where the maintainer
would be allowed to put what he wants). You can find information on that
If you want to quickly know how it works, simply look at the bottom of
the page. There's 2 example, one simple and one complex. That's a way
more easy to understand just by reading the example (the specs are
over-complicated to read, IMHO, but still necessary to be formal).
Also, and that's a rejecting error (not a soft one like above with the
format), your debian/copyright states:
The Debian packaging is copyright 2009, Luis Uribe <acme at eviled.org>
and is licensed under the GPL, see `/usr/share/common-licenses/GPL-2'.
Your package has a debian/patches file which, IMHO, is useless (explain
to me why it should be there otherwise). That's one of the issue when
using the "3.0 (Quit)" format, which makes me stick to the old 1.0
format: I never have this kind of issue, and things are kept simple.
This is wrong. You should put the GPL-2 header there. See the page above
for an example of it. Also, I would suggest you to use the same kind of
license used by the upstream author for your Debian packaging work.
Seeing the upstream work licensed as BSD, and your package being a way
more restrictive with GPL doesn't feels so good (although, this is just
a suggestion). Maybe you may want to use LGPL at least, rather than a
restrictive GPL v2? Also, why using GPL v2 when there's version 3
available? See the video of the FSF guy at last NYC debconf about using
v3 rather than v2, I found it rather convincing.
Hoping that the above helps,
Thanks for your work and your interest in Debian,
Thomas Goirand (zigo)
More information about the pkg-php-maint