Red Hat Bugzilla – Bug 227191
Review Request: php-pear-Services-Yadis - PHP Yadis
Last modified: 2008-12-10 15:34:08 EST
Spec URL: http://dl.atrpms.net/all/php-pear-Services-Yadis.spec SRPM URL: http://dl.atrpms.net/all/php-pear-Services-Yadis-1.0.2-2.at.src.rpm Description: An implementation of the Yadis service discovery protocol.
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.