Bug 170701

Following PackageNamingGuidelines, "the name should match the upstream tarball
or project name from which this software came". Therefore the name should be
"Smarty".

Another reason for this -- normally, "php-something" means an extra module to
php (aka php-ldap.so, php-gd.so etc.)

Why you have commented out Source0 URL?

I was matching php-adodb in extras which is similar.  I think a php library is
much like a perl or python library which get perl- or py prefixes.

Source0 is commented out because it does not build properly with it in.

File
/export/home/orion/redhat/php-Smarty-2.6.10/do_download.php?download_file=Smarty-2.6.10.tar.gz:
No such file or directory

> I was matching php-adodb in extras which is similar.
Sadly, it is another bad example (its upstream name was "adodb"...).

> I think a php library is much like a perl or python library
> which get perl- or py prefixes.
Not all present "noarch" perl or python packages have such prefixes.

Anyway, "php-adodb" is an unique precedent. It would be better to ask about such
a naming in fedora-extras-list .


> Source0 is commented out because it does not build properly with it in.

???
I've download tarball from the location currently commented out, it matches the
tarball in the srpm. What is the reason to not specify full url for the tarball?
(It is "http://smarty.php.net/...", not "/export/home/orion/....")
 

> > I was matching php-adodb in extras which is similar.
> Sadly, it is another bad example (its upstream name was "adodb"...).

I maintain php-adodb. I used the php prefix since there is also a python adodb
module. And since adodb extends php, I thought php-adodb was better than
adodb-php. If you think it's better the other way around, please open a bug, so
we don't pollute this one.

If its a new module extension to php, it should be php-Smarty. If its just an
application that uses php to function, Smarty is ok.

Does that distinction make sense?

It's not an application and it's not strictly a php "module", it's a library (or
framework) written in php for use by php applications.  I doubt that there will
be a "Smarty" impletation in any other language though.  We make pure perl
libraries (or "modules") have perl-, and python use py/python-.  Makes sense to
have php- in this case, but I don't have a strong desire either way.

If I understand correctly, you're saying it isn't an extension to the php
interpreter ("php module").  But how does its being a library differ from, for
instance, php-pear?

Templating modules in other languages are prefaced with the language (e.g.,
python-kid), so I don't see a difference here.

(In reply to comment #3)
> > Source0 is commented out because it does not build properly with it in.
> 
> ???
> I've download tarball from the location currently commented out, it matches the
> tarball in the srpm. What is the reason to not specify full url for the tarball?

Because it doesn't compile with it uncommented.  Try it.  rpmbuild can't parse
the cgi style url.  

(for comment #9)
Yes...
But it is not a final url. Actually, it will be redirected to more good one :)

Use:
"Source0: http://smarty.php.net/distributions/Smarty-%{version}.tar.gz"
it is the actual location.

about adding to the php include_path, I don't think you should modify that
system-wide.  The Smarty documentation, here
http://smarty.php.net/manual/en/installing.smarty.basic.php
gives quite a few ways for people to include the Smarty code in their
application.  Examples 2-3 and 2-5 would work without having to modify php's
include_path.

Does it really make sense to install an app like Smarty from extras? With
php-pear that's a difference imho, since it's an installer in itself. But PEAR
1.4.x allows the usage of channels - and there will be a channel offering
Smarty-releases as well. So the easiest way would be to simply install Smarty
using PEAR. And imho in the PHP-world more and more apps use PEAR anyway, so
it's already there.

Imho for PHP-apps it would make more sense to install those using the
PEAR-installer.

(In reply to comment #10)
> Use:
> "Source0: http://smarty.php.net/distributions/Smarty-%{version}.tar.gz"
> it is the actual location.

Thanks!

(In reply to comment #12)
> Does it really make sense to install an app like Smarty from extras? With
> php-pear that's a difference imho, since it's an installer in itself. But PEAR
> 1.4.x allows the usage of channels - and there will be a channel offering
> Smarty-releases as well. So the easiest way would be to simply install Smarty
> using PEAR. And imho in the PHP-world more and more apps use PEAR anyway, so
> it's already there.

Yeah, and perl has CPAN.  But we have *lots* of perl-* RPMs to allow for a
common mechanism to install software.

(In reply to comment #14)
> Yeah, and perl has CPAN.  But we have *lots* of perl-* RPMs to allow for a
> common mechanism to install software.

And to deal with dependencies...
From a pure packaging point of view, this package looks clean. I don't know of a
way to properly add a path to php's include_path, but it does not seem necessary
anyway.
Please provide a package with a full Source0 tag.

Fixed Source0 URL:

http://www.cora.nwra.com/~orion/fedora/php-Smarty-2.6.10-2.src.rpm

Review for release 2:
* RPM name is OK
* Source Smarty-2.6.10.tar.gz is the same as upstream
* Builds fine in mock
* rpmlint of php-Smarty looks OK
* File list of php-Smarty looks OK
* Works fine.
APPROVED

Checked into cvs and builds on devel.

Ownership change request, see:
https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00331.html

New owner should be:  chris.stone

Package Change Request
======================
Package Name: php-Smarty
New Branches: EL-5

cvs done.