Red Hat Bugzilla – Bug 190937
Review Request: perl-Module-Install
Last modified: 2011-01-19 04:41:13 EST
Spec URL: http://ftp.kspei.com/pub/steve/rpms/perl-Module-Install/perl-Module-Install.spec
SRPM URL: http://ftp.kspei.com/pub/steve/rpms/perl-Module-Install-0.62-1.src.rpm
Module::Install is a package for writing installers for CPAN (or CPAN-like)
distributions that are clean, simple, minimalist, act in a strictly correct
manner with both the ExtUtils::MakeMaker and Module::Build build systems,
and will run on any Perl installation version 5.004 or newer.
The source URL seems to be wrong; is upstream really on your site? CPAN says
which I'll take as upstream for the purposes fo this review.
One of the tests spits out some warnings because various utilities are missing;
is it worth adding additional BR:s to get more coverage?
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written, uses macros consistently and
follows the Perl specfile template.
* license field matches the actual license.
* license is open source-compatible. It's not included separately in the
package, but this is not necessary as the upstream tarball does not include it.
* source files match upstream:
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (development, x86_64).
* rpmlint is silent.
* final provides and requires are sane (many manual Requires: not picked by
* no shared libraries are present.
* 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.
* %clean is present.
* %check is present and all tests pass:
All tests successful.
Files=4, Tests=51, 2 wallclock secs ( 0.58 cusr + 0.26 csys = 0.84 CPU)
* 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.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
(In reply to comment #1)
> The source URL seems to be wrong; is upstream really on your site? CPAN says
> which I'll take as upstream for the purposes fo this review.
Oops, apparently I forgot to unset CPAN before running cpanspec. Sorry.
> One of the tests spits out some warnings because various utilities are missing;
> is it worth adding additional BR:s to get more coverage?
Definitely. Did you happen to save a build log? (It would save me another mock
OK, I see the warnings now:
t/03_audotinstall....ok 1/6Warning: links not found in PATH
Warning: wget not found in PATH
Warning: ncftpget not found in PATH
Warning: ncftp not found in PATH
Warning: ftp not found in PATH
Warning: gpg not found in PATH
I wonder if it might be safer to leave those BRs out so it can't do any network
We certainly don't want it doing network access; I saw the gpg warning and
wondered if it was going to test something relating to signing.
I believed the warnings are harmless and are being emitted by the CPAN module
that this module loads. It must be complaining about the missing configuration.
The gpg, ftp, ncftp*, wget are CPAN configuration variables.
See the output of
$ perl -MCPAN -e shell
cpan> o conf
or the contents of a CPAN configuration file
I'll ignore the warnings then.
The package has been imported into CVS, branches have been created, and builds
have been requested.
This package is in EPEL5, but not in EPEL6. Is there any reason for that?
I would like to see this package in EPEL6, and I am willing to help co-maintain it.
Nevermind, I just saw it's in the RHEL6 Client repository (I was only looking at the Server one).
Sorry for the spam.