Bug 227191

What is the difference between 
- http://pear.php.net/package/Services_Yadis/ (version 0.2.0)
- http://www.openidenabled.com/openid/libraries/php (version 1.0.2)

Name are same.
So if they are different, we have to handle this using "channel" namespace.

Regards.

(In reply to comment #1)
> What is the difference between 
> - http://pear.php.net/package/Services_Yadis/ (version 0.2.0)
> - http://www.openidenabled.com/openid/libraries/php (version 1.0.2)
> 
> Name are same.
> So if they are different, we have to handle this using "channel" namespace.

This was resolved upstream by absorbing the latter into php-openid.

I'll review it.

404 while downloading srpm. Axel, please, update link.

http://dl.atrpms.net/all/php-pear-Services-Yadis-1.0.2-2.src.rpm

I made some little changes since Services_Yadis-1.0.2.tgz tarball was rebuilt
and moved to new destination. Now it can be downloaded from the following:

http://openidenabled.com/files/php-openid/files/PHP-yadis-1.0.2.tar.gz

Another two minor changes was to rename BuildRoot and to add empty %build-section.

There are slightly modified files:

http://peter.fedorapeople.org/php-pear-Services-Yadis.spec
http://peter.fedorapeople.org/php-pear-Services-Yadis-1.0.2-2.fc9.src.rpm

REVIEW:

- rpmlint is not silent. It complains to wring license, LGPL. We should add
actual license (LGPLv1, LGPLv2+ or something else). BTW I found mentions of
non-existent COPYING file in sources. Maybe we should provide it? Another
confusing thing is that there is MPL-1.1.txt file among %docs.

+ The package must be named according to the Package Naming Guidelines.
+ The spec file name must match the base package %{name}, in the format
%{name}.spec unless your package has an exemption on Package Naming Guidelines.
+ The package must meet the Packaging Guidelines.
+ The package must be licensed with a Fedora approved license and meet the
Licensing Guidelines.
+ The License field in the package spec file must match the actual license.
+ The spec file must be written in American English.
+ The spec file for the package MUST be legible.
+ The sources used to build the package must match the upstream source, as
provided in the spec URL. 
+ The package must successfully compile and build into binary rpms on at least
one supported architecture.

+/- All build dependencies must be listed in BuildRequires. I think we also need
to Require those packages that provide %dir %{pear_phpdir}/Auth/Services if any.

- A package must own all directories that it creates. I think we must include
the following line in the %files section:

%dir %{pear_phpdir}/Auth/Services/Yadis


+ A package must not contain any duplicate files in the %files listing.
+ Permissions on files must be set properly. 
+ Each package must have a %clean section, which contains rm -rf %{buildroot}
(or $RPM_BUILD_ROOT).
+ Each package must consistently use macros, as described in the macros section
of Packaging Guidelines.
+ The package must contain code, or permissable content. This is described in
detail in the code vs. content section of Packaging Guidelines.
+ If a package includes something as %doc, it must not affect the runtime of the
application. To summarize: If it is in %doc, the program must run properly if it
is not present.
+ At the beginning of %install, each package MUST run rm -rf %{buildroot} (or
$RPM_BUILD_ROOT). 

Summarizing things:

* we should fix license field in spec-file and add proper COPYING file into %docs
* we should own only our directory and add Requires for those packages that own
upper directories

Ping!

(In reply to comment #6)
> * we should fix license field in spec-file and add proper COPYING file into %docs
> * we should own only our directory and add Requires for those packages that own
> upper directories

The licensing mess is indeed a mess. I think this need upstream to clarify the
intentions. :/

On the directories: It doesn't require any /Auth or /Auth/Services owning
packages. The path naming is just convention. That's why I chose to own the
parents as well to not introduce artificial dependencies. The guidelines require
either to Require in the owning packages or coown the upper folders.

* I think this need upstream to clarify the intentions. :/

Agree. 

About directory ownersip - seems that the multiple ownership of php-pear-*
packages is a common practice:

*
http://cvs.fedoraproject.org/viewcvs/rpms/php-pear-Auth-RADIUS/devel/php-pear-Auth-RADIUS.spec?rev=1.1&view=auto
*
http://cvs.fedoraproject.org/viewcvs/rpms/php-pear-Auth-SASL/devel/php-pear-Auth-SASL.spec?rev=1.2&view=auto

I think that we shouldn't clean this mess :)

OK, let's clarify licensing terms. Could you, please, ask upstream?

s/seems that the multiple ownership of php-pear-* packages is a common
practice/seems that the multiple ownership of directories is a common practice
for php-pear-* packages/g

Does this package superceded by php-pear-Auth-OpenID? I quickly looked inside and found that directories PHP-yadis-1.0.2/Services/Yadis and php-openid-2.1.1/Auth/Yadis looks quite similar.

Axel, does this package superceded by php-pear-Auth-OpenID?

Ping.

I don't know if it is superseded, but it was just needed (from my part) as part of a dependency chain of which it fell off by now.

As I have no direct interest in this package any more I suggest to drop/orphan he review.

ok.