[pkg-php-pear] Twing in Debian (was: Found a nice tool that needs a maintainer: jq)
zigo at debian.org
Fri Jul 26 18:11:28 UTC 2013
On 07/27/2013 12:40 AM, Daniel Beyer wrote:
> Hi Thomas,
> I would have been interested in doing so, but it seems that jq already
> found its way into Debian:
> But if you like to do some sponsoring, I'm still waiting for someone to
> sponsor twig (or even give me some feedback regarding the packaging):
> Don't mind, I just thought I'll give that a try, since you maintain
> quite some php stuff... ;-)
> Greetings from Swiss
Ok, here my remarks.
1/ Package descptions
Your long descriptions are a bit weird. Could you please remove the
indentation thing, and replace it with paragraphs instead?
I don't really like seeing:
"For more details about the Twig template engine see the twig package
please remove that and replace it by a (short) description of twig.
Also, the short description of "php5-twig-extension" is: "Twig php5
extension". This doesn't help. Please write things which aren't in the
package name already.
In fact, you've just copied what's on the home page of
http://twig.sensiolabs.org/. That is sometimes a good approach, but not
In debian/twig.README.Debian, I can see:
Twig is a fast, secure and flexible template engine for php,
implementing an own domain specific language which originated from Jinja
and Django templates. It optionally can make use of a php5 extension,
that enhances its performance.
That's much better. Why don't you use that?
There's all sorts of indentation there. Please clean that.
The files in /usr/share/php/Twig/Test belong to the doc folder, and IMO,
shouldn't be packaged together with the library. This can (potentially)
be a security problem, if some of the test scripts are doing nasty
things (I didn't check). Putting them in /usr/share/doc can be a solution.
4/ The PHP .so extension
I don't really know much about packaging PHP .so libs, so probably
someone else will have to look at that. For example, I'm not sure if
extensions should be activated by default, unconditionally, on upgrades
(what if the admin decided to deactivate it, but leave the package
installed, and it gets upgraded?).
Can anyone from the team have a look and let Daniel and I know?
Is there a document where to read about this?
5/ Team maintenance
May I suggest that you team-maintain this package, using Git and
git-buildpackage? You may want to read this:
It is generally a good idea to ask different teams for sponsoring, and
often achieves much better results than just filling a RFS bug or
writing to the mentor's list.
Thomas Goirand (zigo)
More information about the pkg-php-pear