Spec URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG-1.63-1.fc10.src.rpm Description: The Crypt::GPG module provides access to the functionality of the GnuPG (www.gnupg.org) encryption tool through an object oriented interface. It provides methods for encryption, decryption, signing, signature verification, key generation, key certification, export and import.
please enable tests. use %check make test Can you resubmit spec that will follow https://fedoraproject.org/wiki/Packaging/Perl? Also, you can use "cpanspec Crypt-GPG" to create spec file. see https://fedoraproject.org/wiki/Perl/cpanspec
Parag, can you please point out, where my spec file does not match with the https://fedoraproject.org/wiki/Packaging/Perl guidelines? The following list compares https://fedoraproject.org/wiki/Packaging/Perl with my spec file where "NA" means that it doesn't applicate here and "--" that I'm missing it. The only thing, I'm really missing is %check, that's right. And that's solved in -2 now. [OK] License tag [OK] Directory Ownership [OK] Perl Requires and Provides [OK] Core modules as buildrequires [OK] Versioned MODULE_COMPAT_ Requires [NA] Filtering Requires: and Provides [OK] Manual Requires and Provides [OK] URL tag [--] Testing and Test Suites [NA] When to *not* test [NA] Conditionally enabling/disabling tests [OK] Makefile.PL vs Build.PL [NA] .h files in module packages Why should I use cpanspec if my spec file is valid and follows the policies? Spec URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG-1.63-2.src.rpm
Looks reasonable to me except that you shouldn't be generating and shipping the COPYING and Artistic files since they're not included in the upstream distribution.
According to bug #225735 comment #9 from Fedora Legal it doesn't really matter which license file is shipped within the RPM package. There upstream shipped a GPLv3 license file for a GPLv2-only software. And at bug #193960 comment #6 I even got asked to generate the missing license file to avoid confusion, which is the same situation here IMHO. I already sent an upstream request to add this file for newer releases.
The request in which you were asked to generate the missing file is somewhat dated - in fact it was common practice amongst the perl SIG at that time to add the files. However, since then the packaging guidelines have changed and now quite clearly state that license text should be included if and only if upstream includes them: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc
(In reply to comment #5) > The request in which you were asked to generate the missing file is somewhat > dated - in fact it was common practice amongst the perl SIG at that time to add > the files. However, since then the packaging guidelines have changed and now > quite clearly state that license text should be included if and only if > upstream includes them: > > https://fedoraproject.org/wiki/Packaging:ReviewGuidelines > > MUST: If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) for the > package must be included in %doc I agree here. This is one point that I see capnspec does not needed to create manually COPYING and Artistic files.
I'll drop COPYING and Artistic files generation, if that makes you happy. What else has to be changed or work needs to happen?
(In reply to comment #2) > > Why should I use cpanspec if my spec file is valid and follows the policies? > 1)Can you please tell me why its needed to use PREFIX=%{_prefix} in %build. 2) according to standard perl spec template, I see that %install should use make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';' chmod -R u+w $RPM_BUILD_ROOT/* I will leave this to you. If you are unhappy with this do tell me.
Usually using "pure_install" fails on RHEL 4, looks like this package is an exception compared to others, tested it explicitly on RHEL 4 few minutes ago. Spec URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG.spec SRPM URL: http://labs.linuxnetz.de/bugzilla/perl-Crypt-GPG-1.63-3.src.rpm
As you are more confident enough about your packaging I am approving this based on comment#2.
Parag, thanks for your review. New Package CVS Request ======================= Package Name: perl-Crypt-GPG Short Description: Perl Object Oriented Interface to GnuPG Owners: robert Branches: EL-4 EL-5 F-10 F-11 InitialCC: perl-sig
CVS done.
perl-Crypt-GPG-1.63-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/perl-Crypt-GPG-1.63-3.fc10
Package: perl-Crypt-GPG-1.63-3.fc12 Tag: dist-f12 Status: complete Package: perl-Crypt-GPG-1.63-3.fc11 Tag: dist-f11-updates-candidate Status: complete Package: perl-Crypt-GPG-1.63-3.fc10 Tag: dist-f10-updates-candidate Status: complete 2463 (perl-Crypt-GPG): Build on target fedora-5-epel succeeded. 2464 (perl-Crypt-GPG): Build on target fedora-4-epel succeeded.
perl-Crypt-GPG-1.63-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
perl-Crypt-GPG-1.63-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.