Red Hat Bugzilla – Bug 199028
Review Request: perl-eperl
Last modified: 2007-11-30 17:11:37 EST
Spec URL: http://ftp.kspei.com/pub/steve/rpms/perl-eperl/perl-eperl.spec
SRPM URL: http://ftp.kspei.com/pub/steve/rpms/perl-eperl-2.2.14-2.src.rpm
ePerl interprets an ASCII file bristled with Perl 5 program statements
by evaluating the Perl 5 code while passing through the plain ASCII
data. It can operate in various ways: As a stand-alone Unix filter or
integrated Perl 5 module for general file generation tasks and as a
powerful Webserver scripting language for dynamic HTML page
The documentation and latest release can be found on
Note that this package does not include the Apache::ePerl module,
which is designed for mod_perl 1.x.
I struggled with the naming a bit, as eperl is more than just a perl module.
However, it is indeed a module "and then some", which I believe makes it
appropriate to prefix "perl-". The website and documentation also switch from
"ePerl" to "eperl" fairly frequently, so I defer to the packager.
+ 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. (GPL or Artistic)
+ License text included in package.
+ source files match upstream:
+ latest version is being packaged.
+ BuildRequires are proper.
package builds in mock (devel/fc5 x86_64).
+ rpmlint is silent.
+ final provides and requires are sane:
Perl(Parse::ePerl) = 2.2.14
perl-eperl = 2.2.14-2.fc5
perl >= 0:5.00325
+ no shared libraries in the system dynamic paths 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=7, Tests=9, 0 wallclock secs ( 0.16 cusr + 0.11 csys = 0.27 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.
+ not a web app.
(In reply to comment #1)
> I struggled with the naming a bit, as eperl is more than just a perl module.
> However, it is indeed a module "and then some", which I believe makes it
> appropriate to prefix "perl-". The website and documentation also switch from
> "ePerl" to "eperl" fairly frequently, so I defer to the packager.
I was going for perl-$CPAN_name (even though is isn't on CPAN). It's as
appropriate as anything...
It's been imported into CVS, branches have been created, and builds have been