What's a correct naming scheme for PHP extensions (written on compiled language, e.g. C)?

[Sergey B Kirpichev]

Here is
http://webapps-common.alioth.debian.org/draft-php/html/ch-php-int.html#s-php-interpreter-naming
which describe naming convention:
----->8----
phpPHPVERSION-PHPMODULENAME
One of a small collection of prebuilt php modules such as
php4-mysql, which are included with PHP by the upstream authors.
---->8----
and policy for naming PEAR libraries:
http://webapps-common.alioth.debian.org/draft-php/html/ch-php-libs.html#s-php-libs-pear
--->8----
Debianized PHP libraries should be prefixed to identify themselves as
such. The naming
scheme should follow that of other languages (such as perl, ruby, and
python) and name
packages in the form libPEARLIBRARYNAME-php. Optionally, if the php
library only works
with a specific version of php libPEARLIBRARYNAME-phpPHPVERSION. would
also be acceptable.
--->8----

The first is for core PHP modules, the later looks like for
written in PHP libraries (e.g. requirement: "PHP libraries should
be located in /usr/share/php/PACKAGE").

What's a correct naming scheme for PHP external extensions (not in core), either
from pecl.php.net or not: phpVERSION-EXTENSIONNAME (e.g.: php5-xcache,
php5-geoip) or libEXTENSIONNAME-php (e.g.: libssh2-php). The first
one seems to be more popular.

PS: Please CC me if you answer on this, I'm not subscribed to this list.

[sean finney]

Hi Sergey,

Post by Sergey B Kirpichev
----->8----
phpPHPVERSION-PHPMODULENAME
One of a small collection of prebuilt php modules such as
php4-mysql, which are included with PHP by the upstream authors.
---->8----

Without thinking too hard, i think this guy is the way to go. the
document is perhaps a bit vague here but i think that this is both
the intention and what is most commonly done in practice.

anyone disagree?


sean

[Sergey B Kirpichev]

Post by Sergey B Kirpichev
----->8----
phpPHPVERSION-PHPMODULENAME
One of a small collection of prebuilt php modules such as
php4-mysql, which are included with PHP by the upstream authors.
---->8----

Without thinking too hard, i think this guy is the way to go.  the
document is perhaps a bit vague here but i think that this is both
the intention and what is most commonly done in practice.
anyone disagree?

So, I'm right in opening this bugreport:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611983

Is this policy violation or not?

[Sean Finney]

Hi Sergey,

Post by Sergey B Kirpichev
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611983
Is this policy violation or not?

Well it's not a "policy violation" in the sense that the PHP Policy
Draft is not actually Debian Policy, but the draft for a set of
recommendations. It also seems that the draft is... well... ambiguous
enough on a few points that it's not read the same way by different
packagers.

yes i would agree that if it's a pre-compiled pecl module that phpN-pkg
is more appropriate, but it's nothing I'd shed any tears over since it
is fairly inconsistent already.


sean

[Sergey B Kirpichev]

Post by Sean Finney
Well it's not a "policy violation" in the sense that the PHP Policy
Draft is not actually Debian Policy, but the draft for a set of
recommendations.

Anyway, you got an idea.

Post by Sean Finney
It also seems that the draft is... well... ambiguous
enough on a few points that it's not read the same way by different
packagers.
yes i would agree that if it's a pre-compiled pecl module that phpN-pkg
is more appropriate, but it's nothing I'd shed any tears over since it
is fairly inconsistent already.

Hope, it's time to fix this. I'm also surprised why
Debian PHP Maintainers are outside of this
policy creation process.

Where I can find source (SGML or whatever) of this policy document?