SRPM URL: http://home.comcast.net/~ckweyl/perl-Params-Coerce-0.13-1.fc5.src.rpm
SPEC URL: http://home.comcast.net/~ckweyl/perl-Params-Coerce.spec
A big part of good API design is that we should be able to be flexible in
the ways that we take parameters.
I have to say that the %description leaves a bit to be desired. Could you
perhaps add the second paragraph from the DESCRIPTION section of the documentation?
* source files match upstream:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible. License text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* rpmlint is silent.
* final provides and requires are sane:
perl(Params::Coerce) = 0.13
perl-Params-Coerce = 0.13-1.fc6
* %check is present and all tests pass:
All tests successful.
Files=5, Tests=48, 0 wallclock secs ( 0.16 cusr + 0.08 csys = 0.24 CPU)
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
+Import to CVS
+Add to owners.list
+Bump release, build for devel
+Request branching (FC-5)
(In reply to comment #1)
> I have to say that the %description leaves a bit to be desired. Could you
> perhaps add the second paragraph from the DESCRIPTION section of the
Please branch for EL-4, EL-5.
perl-Params-Coerce-0.14-11.el4 has been submitted as an update for Fedora EPEL 4.