Issue with PHP Naming guidelines

[Jason L Tibbitts III]

The PHP guidelines seem rather clear that PHP modules all require a
"php-" prefix (with some types of modules requiring additional
designations like "php-pear-").  Recently I noticed that two modules,
phpFlickr and phpSmug, were both submitted and approved.  I held off
on doing CVS for the latter; the reviewer's reasoning is as follows:

"The php guidelines not withstanding, php-phpSmug struck me as
unnecessary duplication and the same with php-phpFlickr."

https://bugzilla.redhat.com/show_bug.cgi?id=510979

In general, I think it's the job of the reviewer to point out issues
in the guidelines rather than to simply ignore them.  However, what's
done is done (unless we want to force a rename of phpFlickr, which has
already been imported) but I figured I'd ask if FPC wants to consider
ammending the guidelines to cover this case, or suggest another name
for this package.  Personally I'm not really inclined to an exception,
because we have other packages like php-pear-PHP-CodeSniffer.noarch,
php-pear-PHPUnit.noarch, php-pear-PhpDocumentor.noarch with no
complaints about naming, but also phpTodo, phpMyAdmin and phpPgAdmin
which are not modules but applications which happen to have PHP in
their names.

 - J<

[Christopher Stone]

On Sat, Jul 18, 2009 at 7:00 AM, Jason L Tibbitts III<tibbs(a)math.uh.edu> wrote:
>  The PHP guidelines seem rather clear that PHP modules all require a
>  "php-" prefix (with some types of modules requiring additional
>  designations like "php-pear-").  Recently I noticed that two modules,
>  phpFlickr and phpSmug, were both submitted and approved.  I held off
>  on doing CVS for the latter; the reviewer's reasoning is as follows:
>
>  "The php guidelines not withstanding, php-phpSmug struck me as
>  unnecessary duplication and the same with php-phpFlickr."
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=510979
>
>  In general, I think it's the job of the reviewer to point out issues
>  in the guidelines rather than to simply ignore them.  However, what's
>  done is done (unless we want to force a rename of phpFlickr, which has
>  already been imported) but I figured I'd ask if FPC wants to consider
>  ammending the guidelines to cover this case, or suggest another name
>  for this package.  Personally I'm not really inclined to an exception,
>  because we have other packages like php-pear-PHP-CodeSniffer.noarch,
>  php-pear-PHPUnit.noarch, php-pear-PhpDocumentor.noarch with no
>  complaints about naming, but also phpTodo, phpMyAdmin and phpPgAdmin
>  which are not modules but applications which happen to have PHP in
>  their names. 
I think these applications fall under the: "Note that web applications
that happen to be written in PHP do not belong under the php-*
namespace." part of the PHP guidelines.

These applications are not installing .so files in %{_libdir}/php, but
rather php files in %{_datadir}/php
Well atleast phpSmug, I did not look at phpFlickr.

Hope this clarifies things, please correct me if I'm mistaken.

Best Regards,
Chris

[Jason L Tibbitts III]

> >>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes: 
CS> I think these applications fall under the: "Note that web
CS> applications that happen to be written in PHP do not belong under
CS> the php-* namespace." part of the PHP guidelines.

I'm not sure I understood this response.  The only reason I mentioned
applications was to point out that there are a few packages which
start with php* that aren't PHP modules, but that the two packages I
was questioning explicitly do not fit into that category.  Maybe I
shouldn't have mentioned them at all, because it seems to have
confused the issue.  Do I need to re-post my original message
without that mention?

CS> These applications are not installing .so files in %{_libdir}/php,
CS> but rather php files in %{_datadir}/php Well atleast phpSmug, I
CS> did not look at phpFlickr.

My understanding is that phpSmug and phpFlickr are indeed PHP modules,
no different from php-Smarty.  Since they're not pear or pecl modules,
they fall under "Other packages should be named
php-PackageName-%{version}-%{release}.%{arch}.rpm; %{arch} can be
"noarch" where appropriate."

http://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme

 - J<

[Christopher Stone]

On Sat, Jul 18, 2009 at 9:01 AM, Jason L Tibbitts III<tibbs(a)math.uh.edu> wrote:
> >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>
>  CS> I think these applications fall under the: "Note that web
>  CS> applications that happen to be written in PHP do not belong under
>  CS> the php-* namespace." part of the PHP guidelines.
>
>  I'm not sure I understood this response.  The only reason I mentioned
>  applications was to point out that there are a few packages which
>  start with php* that aren't PHP modules, but that the two packages I
>  was questioning explicitly do not fit into that category.  Maybe I
>  shouldn't have mentioned them at all, because it seems to have
>  confused the issue.  Do I need to re-post my original message
>  without that mention?
>
>  CS> These applications are not installing .so files in %{_libdir}/php,
>  CS> but rather php files in %{_datadir}/php Well atleast phpSmug, I
>  CS> did not look at phpFlickr.
>
>  My understanding is that phpSmug and phpFlickr are indeed PHP modules,
>  no different from php-Smarty.  Since they're not pear or pecl modules,
>  they fall under "Other packages should be named
>  php-PackageName-%{version}-%{release}.%{arch}.rpm; %{arch} can be
>  "noarch" where appropriate."
>
>  http://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme 
No, I'm arguing that a php module as being defined as something which
puts a .so file under %{_libdir}/php.

I too was just considering the php-Smarty case.  It is a package which
I own, but was originally owned by someone else.  I tried to find the
review request on php-Smarty to see if this issue came up, but could
not find it (my searching skillz might need improvement), if you can
find the review and it mentions this issue, please provide a link.
However, I would think that php-Smarty could (and perhaps should) be
actually named just "Smarty".

[Jason L Tibbitts III]

> >>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes: 
CS> No, I'm arguing that a php module as being defined as something
CS> which puts a .so file under %{_libdir}/php.

So pear packages aren't PHP modules?  They're all noarch (pretty much
by definition) and so don't have .so files.

 - J<

[Remi Collet]

Le 18/07/2009 18:19, Jason L Tibbitts III a écrit :
> >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  
>  CS> No, I'm arguing that a php module as being defined as something
>  CS> which puts a .so file under %{_libdir}/php.
>  
>  So pear packages aren't PHP modules?  They're all noarch (pretty much
>  by definition) and so don't have .so files. 
I think tibbs is right in his first post

PHP Web app, (generally under /usr/share/appname) is out of php-*
namespace and is called appname (phpMyAdmin, glpi, foo)

A PHP extension, written in PHP, providing some classes, is installed
under /usr/share/php (to benefit of default include_path) and is under
the php-* namespace, so must be called php-foo (according to the actual
PHP Guidelines)

If I well understand, the question is
Should we make an exception if name already start by php to avoid
php-phpxxx.

Personaly, I think php- prefix should be add to "all" extensions.


+

[Christopher Stone]

On Sat, Jul 18, 2009 at 9:37 AM, Remi Collet<Fedora(a)famillecollet.com> wrote:
>  Le 18/07/2009 18:19, Jason L Tibbitts III a écrit :
> >>>>>> "CS" == Christopher Stone <chris.stone(a)gmail.com&gt;
> writes:
> >
> > CS> No, I'm arguing that a php module as being defined as something
> > CS> which puts a .so file under %{_libdir}/php.
> >
> > So pear packages aren't PHP modules?  They're all noarch (pretty much
> > by definition) and so don't have .so files.
>
>  I think tibbs is right in his first post
>
>  PHP Web app, (generally under /usr/share/appname) is out of php-*
>  namespace and is called appname (phpMyAdmin, glpi, foo)
>
>  A PHP extension, written in PHP, providing some classes, is installed
>  under /usr/share/php (to benefit of default include_path) and is under
>  the php-* namespace, so must be called php-foo (according to the actual
>  PHP Guidelines)
>
>  If I well understand, the question is
>  Should we make an exception if name already start by php to avoid
>  php-phpxxx.
>
>  Personaly, I think php- prefix should be add to "all" extensions. 
Okay, I found the review[1] and the exact same discussion took place
in Oct 2005 ;-)

I stand corrected.  Thanks. :)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=170701

[Tim Jackson]

On 18/07/09 15:00, Jason L Tibbitts III wrote:

>  The PHP guidelines seem rather clear that PHP modules all require a
>  "php-" prefix (with some types of modules requiring additional
>  designations like "php-pear-").  Recently I noticed that two modules,
>  phpFlickr and phpSmug, were both submitted and approved.  I held off
>  on doing CVS for the latter; the reviewer's reasoning is as follows:
>
>  "The php guidelines not withstanding, php-phpSmug struck me as
>  unnecessary duplication and the same with php-phpFlickr." 
I can see the point, but I agree think we should leave the guidelines as is. 
php-phpFlickr *does* sound a bit clumsy, but at least it's consistent. 
Otherwise, if I saw phpXXX in a package listing, I would think it's an app 
like phpMyAdmin, rather than a library.

Tim

[Christopher Stone]

On Sat, Jul 18, 2009 at 10:04 AM, Tim Jackson<lists(a)timj.co.uk> wrote:
>  On 18/07/09 15:00, Jason L Tibbitts III wrote:
>
> > The PHP guidelines seem rather clear that PHP modules all require a
> > "php-" prefix (with some types of modules requiring additional
> > designations like "php-pear-").  Recently I noticed that two modules,
> > phpFlickr and phpSmug, were both submitted and approved.  I held off
> > on doing CVS for the latter; the reviewer's reasoning is as follows:
> >
> > "The php guidelines not withstanding, php-phpSmug struck me as
> > unnecessary duplication and the same with php-phpFlickr."
>
>  I can see the point, but I agree think we should leave the guidelines as is.
>  php-phpFlickr *does* sound a bit clumsy, but at least it's consistent.
>  Otherwise, if I saw phpXXX in a package listing, I would think it's an app
>  like phpMyAdmin, rather than a library. 
I don't know if the guidelines would strictly allow for it, but it
seems php-Smug, php-Flickr would be an acceptable compromise.

Regards,
Chris

[Tim Jackson]

On 18/07/09 18:06, Christopher Stone wrote:

>  I don't know if the guidelines would strictly allow for it, but
> it
>  seems php-Smug, php-Flickr would be an acceptable compromise. 
Maybe, but it makes it sound like the library is called "Flickr" rather than 
"phpFlickr". I wouldn't necessarily think that "php-Flickr" is the
same thing 
as "phpFlickr". So I'd personally prefer the clumsier but more accurate 
php-phpFlickr.

Tim

[Gianluca Sforna]

On Sat, Jul 18, 2009 at 7:40 PM, Tim Jackson<lists(a)timj.co.uk> wrote:
>  Maybe, but it makes it sound like the library is called
> "Flickr" rather than
>  "phpFlickr". I wouldn't necessarily think that "php-Flickr" is
> the same
>  thing as "phpFlickr". So I'd personally prefer the clumsier but more
>  accurate php-phpFlickr. 
What about adding an exception for the "add the php- prefix" rule  to
packages that includes "php in their name?

Pyhton has something similar:
If the upstream source has "py" (or "Py") in its name, you can use
that name for the package. So, for example, pygtk is acceptable.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

[Toshio Kuratomi]

On 07/19/2009 10:18 AM, Gianluca Sforna wrote:
>  On Sat, Jul 18, 2009 at 7:40 PM, Tim Jackson<lists(a)timj.co.uk>
> wrote:
> > Maybe, but it makes it sound like the library is called "Flickr" rather
> than
> > "phpFlickr". I wouldn't necessarily think that "php-Flickr"
> is the same
> > thing as "phpFlickr". So I'd personally prefer the clumsier but more
> > accurate php-phpFlickr.
>  
>  What about adding an exception for the "add the php- prefix" rule  to
>  packages that includes "php in their name?
>  
>  Pyhton has something similar:
>  If the upstream source has "py" (or "Py") in its name, you can use
>  that name for the package. So, for example, pygtk is acceptable.
>   
That's possible.  OTOH, I personally have argued for removing that  from
the python Guidelines (old package grandfathered in, new packages
needing to be python-pygtk, for example).

-Toshio

[Christopher Stone]

On Sun, Jul 19, 2009 at 10:18 AM, Gianluca Sforna<giallu(a)gmail.com> wrote:
>  What about adding an exception for the "add the php-
> prefix" rule  to
>  packages that includes "php in their name? 
So, a package called "graphplotter" would be valid because it has php
it its name?

[Nicolas Mailhot]

Le dimanche 19 juillet 2009 à 12:17 -0700, Christopher Stone a écrit :
>  On Sun, Jul 19, 2009 at 10:18 AM, Gianluca
> Sforna<giallu(a)gmail.com> wrote:
>  > What about adding an exception for the "add the php- prefix" rule  to
>  > packages that includes "php in their name?
>  
>  So, a package called "graphplotter" would be valid because it has php
>  it its name? 
The way we do it with fonts is that we require the -fonts suffix but
forbid repetition in the root name

So you can not have bigfonts-foofont, bigfoofont-fonts or
fontofbigfoo-fonts but only big-foo-fonts.

Also we require lowercase names and use - as word separator (like other
sensible distros such as Debian or Suse who didn't let their package
namespace polluted by WeirdCamelCaseNames).

Arguably, the decision was easier to make since font authors do not
follow any particular logic in naming their archives and a typical font
includes many layers of naming that usually do not agree on case and
separators.

Anyway, that was mainly to dispell the impression our naming conventions
are consistent accross sigs. Every SIG makes its own rules and as long
as they are internally consistent (all packages of the same kind are
named the same way) no one cares much.

-- 
Nicolas Mailhot