[Bug 1127720] Review Request: perl-MooX-ConfigFromFile - Moo eXtension for initializing objects from config file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1127720

Paul Howarth <paul@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|fedora-review?              |fedora-review+



--- Comment #1 from Paul Howarth <paul@xxxxxxxxxxxx> ---
Review
======

rpmlint
-------
perl-MooX-ConfigFromFile.noarch: W: spelling-error Summary(en_US) eXtension ->
extension, extensions, ex tension
perl-MooX-ConfigFromFile.noarch: W: spelling-error Summary(en_US) config -> con
fig, con-fig, configure
perl-MooX-ConfigFromFile.noarch: W: spelling-error %description -l en_US config
-> con fig, con-fig, configure

Requires
--------
perl(Config::Any)
perl(File::Find::Rule)
perl(File::Find::Rule) >= 0.30
perl(FindBin)
perl(Moo) >= 1.003
perl(Moo::Role)
perl(MooX::File::ConfigDir) >= 0.002
perl(strict)
perl(warnings)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Provides
--------
perl(MooX::ConfigFromFile) = 0.002
perl(MooX::ConfigFromFile::ConfigData)
perl(MooX::ConfigFromFile::Role) = 0.002
perl-MooX-ConfigFromFile = 0.002-1.fc22

Review Checklist
----------------
- rpmlint only moans about technical spellings, so no problem there
- package and spec file naming OK
- package meets guidlines
- license is same as perl, which is fine for Fedora and matches the spec
- no upstream license file to include in package
- spec file written in English and is legible
- sources match upstream
- package builds OK in mock for Rawhide x86_64
- buildreqs seem complete
- no locales, libraries, devel files, sub-packages, desktop files etc. to
  concern us
- package is not intended to be relocatable
- directory ownership is fine
- no duplicate files
- permissions are sane
- macro usage is consistent, though I don't really see what advantage the
  use of %{__perl} brings these days
- code, not content
- no large docs to worry about
- docs don't affect runtime
- filenames are all ASCII
- no scriptlets to consider

Notes
-----

Filtering of unversioned dependencies isn't working properly due to missing
'%':
-%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(File::Find::Rule\\)$
-%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(Moo\\)$
-%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(MooX::File::ConfigDir\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Find::Rule\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Moo\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(MooX::File::ConfigDir\\)$

Using "--" Build options would make the package forward-compatible with
Module::Build::Tiny,
should upstream ever decide to switch to that:

%{__perl} Build.PL --installdirs=vendor
./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0

I prefer to see a more specific list of files/directories in the %files list
as this offers some protection against upstream accidentally bundling something
and us accidentally shipping it as a result - reducing the scope of wildcards
can help flag this sort of thing at package build time


None of those are blockers; take what you will from those suggestions.

APPROVED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review





[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]