Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 376531 (perl-Dir-Which) - perl-Dir-Which - Search for directory entries in a list of directories
Summary: perl-Dir-Which - Search for directory entries in a list of directories
Keywords:
Status: CLOSED DEFERRED
Alias: perl-Dir-Which
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 425814 425817 (view as bug list)
Depends On:
Blocks: FE-DEADREVIEW
TreeView+ depends on / blocked
 
Reported: 2007-11-11 21:13 UTC by Jacquelin Charbonnel
Modified: 2009-03-10 15:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-10 15:09:44 UTC
rjones: fedora-review+


Attachments (Terms of Use)

Description Jacquelin Charbonnel 2007-11-11 21:13:36 UTC
Spec URL: http://math.univ-angers.fr/RPMS/Dir-Which.spec
SRPM URL: <http://math.univ-angers.fr/RPMS/perl-Dir-Which-0.3-1.src.rpm>
Description: <Search for directory entries in a list of directories.  This module searches directory entries (files, dirs, links, named pipes...) in a list of directories specified as a path-like string. The path string can be specified in an environment variable or as an argument.>

Comment 1 Jacquelin Charbonnel 2007-11-16 21:03:37 UTC
this is my first package and I need a sponsor

Comment 2 Jason Tibbitts 2007-11-18 04:50:25 UTC
Hmm, cpanspec sure seems to generate prettier Perl module specfiles than
cpan2rpm.  Honestly it would be much simpler if you installed cpanspec, ran
"cpanspec Dir::Which", change License: as appropriate and add
  BuildRequires: perl(Test::More) perl(Test::Pod) perl(Test::Pod::Coverage)
to get a perfectly acceptable package.

I'll go ahead and review the current package, but there are very many negative
comments.  To find more information about many of these, you can consult the
packaging guidelines at http://fedoraproject.org/wiki/Packaging/Guidelines.

It's not usual Fedora style to have all of the specfile tags in lower case, but
it's OK.

Don't use Packager:.

You aren't using the %dist tag in your Release.  It's not mandatory, but for a
new packager it's recommended.  I'd ask that you demonstrate that you understand
how to manage a package across multiple releases without it.  See
http://fedoraproject.org/wiki/Packaging/DistTag for more information.

Don't use Vendor:.

The License: tag isn't proper; see http://fedoraproject.org/Licensing for proper
license tags.  Also note that the CPAN page lists a completely different license.

The URL: should point to something relevant to the package, not just to the CPAN
main page.  Probably http://search.cpan.org/dist/Dir-Which/.

BuildRoot: is not proper; please use one of the approved BuildRoots: or at least
include %{release}.

Don't use Prefix:

You are missing the proper dependency on perl(:MODULE_COMPAT_...).

I am not sure why the complicated %build section is needed.  Why all of the grep
and xargs stuff?  Does it not suffice to do the usual
  %{__perl} Build.PL installdirs=vendor
  ./Build
?  And the "Build test" call goes in %check, not in %build.

%install should not ever call brp-compress.

The entire "SuSE Linux" stuff should all go; this is a Fedora package.

I don't even inderstand the block starting with "%{__perl} -MFile::Find -le '";
why is it needed?

%install and %clean don't need to check that the buildroot isn't "/"; you set it
to something other than "/" earlier in the spec.

I put the  cpanspec-generated spec at
http://www.math.uh.edu/~tibbs/perl-Dir-Which.spec

Comment 3 Jacquelin Charbonnel 2007-11-18 11:48:07 UTC
(In reply to comment #2)
> Hmm, cpanspec sure seems to generate prettier Perl module specfiles than
> cpan2rpm.  Honestly it would be much simpler if you installed cpanspec, ran
> "cpanspec Dir::Which", change License: as appropriate and add
>   BuildRequires: perl(Test::More) perl(Test::Pod) perl(Test::Pod::Coverage)
> to get a perfectly acceptable package.

Done. Thank you. 

Comment 4 Jacquelin Charbonnel 2007-11-24 18:55:30 UTC
What must I do now ?

Comment 5 Parag AN(पराग) 2007-12-16 15:52:11 UTC
*** Bug 425817 has been marked as a duplicate of this bug. ***

Comment 6 Parag AN(पराग) 2007-12-16 15:52:52 UTC
*** Bug 425814 has been marked as a duplicate of this bug. ***

Comment 7 Parag AN(पराग) 2007-12-16 16:02:11 UTC
Jacquelin,
 Will you please provide updated SPEC and SRPM links here that should resolve
issues raised in comment #2?

Comment 8 Jacquelin Charbonnel 2007-12-17 09:21:50 UTC
(In reply to comment #7)
> Jacquelin,
>  Will you please provide updated SPEC and SRPM links here that should resolve
> issues raised in comment #2?

Yes

Comment 9 Jacquelin Charbonnel 2007-12-23 17:41:07 UTC
What must I do now, to continue the processus of validation ?

Comment 10 Richard W.M. Jones 2008-02-28 19:49:42 UTC
Starting review.

Comment 11 Richard W.M. Jones 2008-02-28 20:07:35 UTC
+ rpmlint output
  rpmlint is clean
+ package name satisfies the packaging naming guidelines
+ specfile name matches the package base name
- package should satisfy packaging guidelines
  should filter provides/requires (http://fedoraproject.org/wiki/Packaging/Perl)
+ license meets guidelines and is acceptable to Fedora
+ license matches the actual package license
+ %doc includes license file
+ spec file written in American English
+ spec file is legible
+ upstream sources match sources in the srpm
  md5 a5af1ec69180f9b54e9b07cf4cb8bada
+ package successfully builds on at least one architecture
  i386
+ ExcludeArch bugs filed
  N/A
+ BuildRequires list all build dependencies
+ %find_lang instead of %{_datadir}/locale/*
  N/A
+ binary RPM with shared library files must call ldconfig in %post and %postun
  N/A
+ does not use Prefix: /usr
+ package owns all directories it creates
+ no duplicate files in %files
+ %defattr line
+ %clean contains rm -rf $RPM_BUILD_ROOT
+ consistent use of macros
+ package must contain code or permissible content
+ large documentation files should go in -doc subpackage
  N/A docs are small
+ files marked %doc should not affect package
+ header files should be in -devel
  N/A
+ static libraries should be in -static
  N/A
+ packages containing pkgconfig (.pc) files need 'Requires: pkgconfig'
  N/A
+ libfoo.so must go in -devel
  N/A
+ -devel must require the fully versioned base
  N/A
+ packages should not contain libtool .la files
  N/A
+ packages containing GUI apps must include %{name}.desktop file
  N/A
+ packages must not own files or directories owned by other packages
  N/A
+ %install must start with rm -rf %{buildroot} etc.
+ filenames must be valid UTF-8

Optional:

+ if there is no license file, packager should query upstream
+ translations of description and summary for non-English languages, if available
? reviewer should build the package in mock
? the package should build into binary RPMs on all supported architectures
+ review should test the package functions as described
 scriptlets should be sane
+ pkgconfig files should go in -devel
+ shouldn't have file dependencies outside /etc /bin /sbin /usr/bin or /usr/sbin

--------

Please take a look at the Perl packaging guidelines.  I'm not
sure about this requirement for filtering provides & requires
and as such I've just raised a question on fedora-packaging:

https://www.redhat.com/archives/fedora-packaging/2008-February/msg00111.html

Comment 12 Richard W.M. Jones 2008-02-28 20:41:29 UTC
OK, turns out that the provides and requires are fine for this package.

APPROVED.

Comment 13 Richard W.M. Jones 2008-09-09 13:46:55 UTC
This has been reviewed for quite a while, but the reporter
didn't get sponsorship and/or needs to file a CVS request.

Comment 14 Richard W.M. Jones 2009-03-10 15:09:44 UTC
Closing out.


Note You need to log in before you can comment on or make changes to this bug.