Bug 190582
Summary: | Review Request: perl-Module-ScanDeps - Recursively scan Perl code for dependencies | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jose Pedro Oliveira <jose.p.oliveira.oss> |
Component: | Package Review | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bochecha, steve |
Target Milestone: | --- | Flags: | kevin:
fedora-cvs+
|
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-05-08 21:04:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779, 190937 |
Description
Jose Pedro Oliveira
2006-05-03 19:04:38 UTC
*** Bug 190935 has been marked as a duplicate of this bug. *** The source URL seems wrong (or at least I can't fetch the upstream source from there). I could get it from: http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/Module-ScanDeps-0.59.tar.gz which I'll assume is the correct upstream. The module puts an executable with a .pl extension into bindir. I agree with Steve that this is a bit ugly but as far as I know it's not a blocker. (My own denyhosts package drops denyhosts.py into bindir so I can't really complain.) Review: * 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: 6e20e368ff101d8bc8f31eaa2d81c264 Module-ScanDeps-0.59.tar.gz 6e20e368ff101d8bc8f31eaa2d81c264 Module-ScanDeps-0.59.tar.gz-srpm * latest version is being packaged. * BuildRequires are proper. * package builds in mock (development, x86_64). * rpmlint is silent. * final provides and requires are sane. * 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=1, Tests=20, 2 wallclock secs ( 2.38 cusr + 0.32 csys = 2.70 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. APPROVED, but please double check the source URL and fix if necessary. (In reply to comment #2) > The source URL seems wrong (or at least I can't fetch the upstream source from > there). I could get it from: > http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/Module-ScanDeps-0.59.tar.gz > which I'll assume is the correct upstream. I failed to catch the change of the maintainer. I will correct the URL after importing it. Thanks. Thanks for the review. Imported and built for FC-4, FC-5, and devel. Package Change Request ====================== Package Name: perl-Module-ScanDeps New Branches: EL-4 EL-5 cvs done. 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. |