Spec URL: http://togami.com/~warren/fedora/perl-Net-SSLeay.spec SRPM URL: http://togami.com/~warren/fedora/perl-Net-SSLeay-1.30-4.src.rpm Description: This module offers some high level convinience functions for accessing web pages on SSL servers (for symmetry, same API is offered for accessing http servers, too), a sslcat() function for writing your own clients, and finally access to the SSL api of SSLeay/OpenSSL package so you can write servers or clients for more complicated applications. This package was previously in Extras. It is required for perl-IO-Socket-SSL, which is required for Spamassassin.
jpo, note that we're adding this to Core soon in order to satisfy a dependency of spamassassin.
NEEDSWORK: - Why the Provides: perl-Net_SSLeay = %{version}-%{release} ? Isn't this automatic? - Perl is part of the exception list, no need to list it as a BR RPMLINT only complains about the file modes in the source package, and about the changelog (ignorable as changelog has non dist'd version but release has dist. rpmlint should allow this) W: perl-Net-SSLeay strange-permission perl-Net-SSLeay-1.2.5-CVE-2005-0106.patch 0666 W: perl-Net-SSLeay strange-permission perl-Net-SSLeay-test14.patch 0666 W: perl-Net-SSLeay strange-permission perl-Net-SSLeay.spec 0666 W: perl-Net-SSLeay strange-permission Net_SSLeay.pm-1.30.tar.gz 0666
(In reply to comment #2) > - Why the Provides: perl-Net_SSLeay = %{version}-%{release} ? Isn't > this automatic? No, note Net-SSLeay vs Net_SSLeay, and see the Sun Jul 11 2004 %changelog entry. I renamed it a few years ago because I thought that the upstream Net_SSLeay.pm distribution name doesn't follow general CPAN naming and would be confusing (underscore vs hyphen, trailing .pm). perl-Net-SSLeay just felt right, and FWIW still does to me even if it doesn't strictly follow the current naming guidelines for CPAN packages.
(In reply to comment #2) > RPMLINT only complains about the file modes in the source package, and about the > changelog (ignorable as changelog has non dist'd version but release has dist. > rpmlint should allow this) That's not what it's complaining about. The spec release is -4 but the changelog only has -3. > W: perl-Net-SSLeay strange-permission perl-Net-SSLeay-1.2.5-CVE-2005-0106.patch 0666 > W: perl-Net-SSLeay strange-permission perl-Net-SSLeay-test14.patch 0666 > W: perl-Net-SSLeay strange-permission perl-Net-SSLeay.spec 0666 > W: perl-Net-SSLeay strange-permission Net_SSLeay.pm-1.30.tar.gz 0666 Trivially fixed by chmod 644-ing the files before building the SRPM.
Couldn't we get around the abiquity by just using perl(Net::SLeay) ? Ah, yes, the changelog version needs to be changed, and those files should probably be chmodded in CVS. Fix those issues and I can approve the move of this package from Extras to Core.
(In reply to comment #5) > Couldn't we get around the abiquity by just using perl(Net::SLeay) ? Yes, things depending on the Net::SSLeay module should have a dependency on perl(Net::SSLeay). At the time I did the rename there were some packages using name based dependencies to this so the Provides could not be just dropped. > those files should probably be chmodded in CVS. Shouldn't be needed. Unless something has changed recently, the only thing CVS remembers is whether files have executable bits or not, and permissions like 0666 don't propagate anywhere. Files are usually 0555 or 0444 inside the repo, and on checkout/export they retain the executable status while other bits are set according to the checkouter's umask.
Should I import this after simply removing the perl buildreq?
Warren, fix the changelog entry, remove the Provides lines that aren't needed any more (extras uses module names for deps), and fix the file permissions, then this can come in.
Warren reports the fixes are in CVS, approving package.
Was built into rawhide.