Bug 1064995 - Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
Summary: Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-13 16:40 UTC by Paul Howarth
Modified: 2014-03-17 06:23 UTC (History)
5 users (show)

Fixed In Version: perl-File-Slurp-Tiny-0.003-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-17 06:23:00 UTC
Type: ---
ppisar: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Paul Howarth 2014-02-13 16:40:34 UTC
Spec URL: http://subversion.city-fan.org/repos/cfo-repo/perl-File-Slurp-Tiny/branches/fedora/perl-File-Slurp-Tiny.spec

SRPM URL: http://www.city-fan.org/~paul/extras/perl-File-Slurp-Tiny/perl-File-Slurp-Tiny-0.003-2.fc21.src.rpm

Description: This module provides functions for fast and correct slurping and spewing.

Fedora Account System Username: pghmcfc

Comment 1 Leon Weber 2014-02-13 17:07:46 UTC
This is an **INFORMAL** review:

Possible issues
===============
- Package probably should not own the dir %{perl_vendorlib}/File/, but its
  contents
- %build section should likely use %{__perl} instead of perl
- rm -rf %{buildroot} is no longer necessary
- BuildRoot tag is unnecessary
- %clean section is unnecessary

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Unknown or generated". 2 files have unknown license. Detailed output of
     licensecheck in /home/makerpm/review/1064995-perl-File-Slurp-
     Tiny/licensecheck.txt
[x]: If the package is under multiple licenses, the licensing breakdown must
     be documented in the spec.
[!]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by:
     /usr/share/perl5/vendor_perl/File(perl-File-Which, perl-File-Listing)
[x]: Changelog in prescribed format.
[!]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf %{buildroot} present but not required
[x]: Sources contain only permissible code or content.
[?]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package is named according to the Package Naming Guidelines.
[?]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[?]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 3 files.
[x]: Package complies to the Packaging Guidelines
     Note: except issues above
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Perl:
[x]: Package contains the mandatory BuildRequires and Requires:.
[x]: CPAN urls should be non-versioned.

===== SHOULD items =====

Generic:
[!]: Buildroot is not present
     Note: Invalid buildroot found:
     %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
     See: http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
[!]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: %clean present but not required
[ ]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: Package should compile and build into binary rpms on all supported
     architectures.
[?]: %check is present and all tests pass.
[?]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: perl-File-Slurp-Tiny-0.003-2.fc19.noarch.rpm
          perl-File-Slurp-Tiny-0.003-2.fc19.src.rpm
perl-File-Slurp-Tiny.noarch: W: spelling-error Summary(en_US) slurper -> slurped, slur per, slur-per
perl-File-Slurp-Tiny.src: W: spelling-error Summary(en_US) slurper -> slurped, slur per, slur-per
2 packages and 0 specfiles checked; 0 errors, 2 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint perl-File-Slurp-Tiny
perl-File-Slurp-Tiny.noarch: W: spelling-error Summary(en_US) slurper -> slurped, slur per, slur-per
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'



Requires
--------
perl-File-Slurp-Tiny (rpmlib, GLIBC filtered):
    perl(:MODULE_COMPAT_5.16.3)
    perl(Carp)
    perl(Exporter)
    perl(File::Spec::Functions)
    perl(FileHandle)
    perl(strict)
    perl(warnings)



Provides
--------
perl-File-Slurp-Tiny:
    perl(File::Slurp::Tiny)
    perl-File-Slurp-Tiny



Source checksums
----------------
http://search.cpan.org/CPAN/authors/id/L/LE/LEONT/File-Slurp-Tiny-0.003.tar.gz :
  CHECKSUM(SHA256) this package     : ded61a7ab96db8c6a14466a5984091a60af9b384b3355d06aeaa6433ac977c02
  CHECKSUM(SHA256) upstream package : ded61a7ab96db8c6a14466a5984091a60af9b384b3355d06aeaa6433ac977c02


Generated by fedora-review 0.5.1 (bb9bf27) last change: 2013-12-13
Command line :/usr/bin/fedora-review -b 1064995
Buildroot used: fedora-19-x86_64
Active plugins: Generic, Shell-api, Perl
Disabled plugins: Java, C/C++, Python, fonts, SugarActivity, Ocaml, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG

Comment 2 Leon Weber 2014-02-13 17:45:15 UTC
(In reply to Leon Weber from comment #1)
> - Package probably should not own the dir %{perl_vendorlib}/File/, but its
>   contents

Oh, actually, it should. Nevermind this point. I had to re-read the docs :)

Comment 3 Paul Howarth 2014-02-13 17:54:26 UTC
> - %build section should likely use %{__perl} instead of perl

The guidelines generally discourage the use of macros for commands except where there's a need for the command path to be configurable, and cites %{__python} as an example. In Fedora there have been parallel python2 and python3 stacks so that might seem a reasonable example but Fedora has never shipped more than one version of perl and so there's not really a need for configurability here. So I prefer the tidier, shorter version.

> - rm -rf %{buildroot} is no longer necessary
> - BuildRoot tag is unnecessary
> - %clean section is unnecessary

These are included for EPEL-5 compatibility, which I care about, and are harmless elsewhere.

Thanks for taking a look at the package.

Comment 4 Ralf Corsepius 2014-02-14 03:51:49 UTC
(In reply to Paul Howarth from comment #3)
> > - %build section should likely use %{__perl} instead of perl
> 
> The guidelines generally discourage the use of macros for commands except
> where there's a need for the command path to be configurable, and cites
> %{__python} as an example. In Fedora there have been parallel python2 and
> python3 stacks so that might seem a reasonable example but Fedora has never
> shipped more than one version of perl and so there's not really a need for
> configurability here. So I prefer the tidier, shorter version.
I have always been in favor of "%perl" and consider package which are using perl to be sloppily maintainedd, because it
a) is an absolute path, which avoids picking up an arbitrary "perl" in $PATH, and thus improves deterministic builds
b) the possibility for fedora to ship another perl >> 0 (Perl6, Scls).

Comment 5 Paul Howarth 2014-02-14 10:05:00 UTC
(In reply to Ralf Corsepius from comment #4)
> (In reply to Paul Howarth from comment #3)
> > > - %build section should likely use %{__perl} instead of perl
> > 
> > The guidelines generally discourage the use of macros for commands except
> > where there's a need for the command path to be configurable, and cites
> > %{__python} as an example. In Fedora there have been parallel python2 and
> > python3 stacks so that might seem a reasonable example but Fedora has never
> > shipped more than one version of perl and so there's not really a need for
> > configurability here. So I prefer the tidier, shorter version.
> I have always been in favor of "%perl" and consider package which are using
> perl to be sloppily maintainedd, because it
> a) is an absolute path, which avoids picking up an arbitrary "perl" in
> $PATH, and thus improves deterministic builds

I agree with this but FPC clearly don't care about this because the guidelines discourage the use of macros for commands generally (e.g. "%__cp", "%__mv"), in favour of unadorned commands. It's a bit pointless doing this for some commands but not all. 

> b) the possibility for fedora to ship another perl >> 0 (Perl6, Scls).

Mechanisms for achieving these have yet to be determined, and quite possibly would not involve the %__perl macro. For instance, the dual python stacks in Fedora are handled using separate %__python2 and %__python3 macros rather than redefining %__python.


Note that I'm playing Devil's Advocate here. I don't have a strong opinion on it either way, and am open to using %__perl; I just don't really see the point of it with the guidelines as they are.

Comment 6 Ralf Corsepius 2014-02-21 01:35:11 UTC
(In reply to Paul Howarth from comment #5)
> (In reply to Ralf Corsepius from comment #4)
> > (In reply to Paul Howarth from comment #3)
> > > > - %build section should likely use %{__perl} instead of perl
> > > 
> > > The guidelines generally discourage the use of macros for commands except
> > > where there's a need for the command path to be configurable, and cites
> > > %{__python} as an example. In Fedora there have been parallel python2 and
> > > python3 stacks so that might seem a reasonable example but Fedora has never
> > > shipped more than one version of perl and so there's not really a need for
> > > configurability here. So I prefer the tidier, shorter version.
> > I have always been in favor of "%perl" and consider package which are using
> > perl to be sloppily maintainedd, because it
> > a) is an absolute path, which avoids picking up an arbitrary "perl" in
> > $PATH, and thus improves deterministic builds
> 
> I agree with this but FPC clearly don't care about this because the
> guidelines discourage the use of macros for commands generally (e.g.
> "%__cp", "%__mv"), in favour of unadorned commands. It's a bit pointless
> doing this for some commands but not all. 
It's not a secret that I am in violent disagreement with FPC on this matter and consider enforcing perl in reviews greasy kiddy stuff.

> > b) the possibility for fedora to ship another perl >> 0 (Perl6, Scls).
> 
> Mechanisms for achieving these have yet to be determined,#
Thanks to the widely spread mistake of using perl instead of %__perl this will be a pretty tough exercise.

> and quite possibly
> would not involve the %__perl macro.
My view: %__perl points to the "system default perl", which today happens to be /usr/bin/perl, which happens to be perl5. If %__perl was used consistently, all of perl could be switched to a future perl version at once.
Anyway, I do not see perl6 to arrive any time soon.

> For instance, the dual python stacks in
> Fedora are handled using separate %__python2 and %__python3 macros rather
> than redefining %__python.
Well, the situation on __python is really messed up, IMO. %__python should point to the system default python, while there is nothing wrong in having %__python2 and %__python3 to support packages with specific demands.
 
Anyway, this is way off-topic for a review.

Comment 7 Christopher Meng 2014-02-21 06:13:13 UTC
Perl6? That's Rakudo so far.

Comment 8 Petr Pisar 2014-02-25 15:15:35 UTC
(In reply to Ralf Corsepius from comment #4)
> (In reply to Paul Howarth from comment #3)
> > > - %build section should likely use %{__perl} instead of perl
> > 
[...]
> I have always been in favor of "%perl" and consider package which are using
> perl to be sloppily maintainedd, because it
> a) is an absolute path, which avoids picking up an arbitrary "perl" in
> $PATH, and thus improves deterministic builds

That's very good argument for using absolute paths.

> b) the possibility for fedora to ship another perl >> 0 (Perl6, Scls).

Current Fedora practice is to install all tools into PATH directories. SCLs redefines PATH (and other variables) for this reason. SCLs encapsulate command invocations with "scl enable" in a spec file. (Though we still use %_perl where we need to edit shebangs.)

Perl6 has different executable name. And again any conflicting file names are urged to rename.

The only thing which fits into your idea are alternatives. Although alternatives are real problem (however no-go for Plan-9 tools), I believe short commands bring more clarity into the packaging.

Comment 9 Ralf Corsepius 2014-02-25 15:48:45 UTC
(In reply to Petr Pisar from comment #8)
> (In reply to Ralf Corsepius from comment #4)
> > (In reply to Paul Howarth from comment #3)
> > > > - %build section should likely use %{__perl} instead of perl
> > > 
> [...]
> > I have always been in favor of "%perl" and consider package which are using
> > perl to be sloppily maintainedd, because it
> > a) is an absolute path, which avoids picking up an arbitrary "perl" in
> > $PATH, and thus improves deterministic builds

> Current Fedora practice is to install all tools into PATH directories. SCLs
> redefines PATH (and other variables) for this reason.
Right - One of the design flaws they suffer from. To be honest, SCLs are a bad joke and should not be used for anything, IMNSHO.

> Perl6 has different executable name. 
Today. At one point in (IMO, very distant) future, /usr/bin/perl would point to /usr/bin/perl6 and the current /usr/bin/perl be renamed to /usr/bin/perl5.

> And again any conflicting file names
> are urged to rename.
Right, that's an effect of what I consider to be Fedora's short-sightedness.

However, lets stop this discussion - A review's BZ is not the right place to discuss this.

Comment 10 Petr Pisar 2014-02-26 08:23:51 UTC
URL and Source0 are usable. Ok.
Source archive is original (SHA-256: ded61a7ab96db8c6a14466a5984091a60af9b384b3355d06aeaa6433ac977c02). Ok.
File-Slurp-Tiny-0.003-old-Test::More.patch is Ok.
Summary verified from lib/File/Slurp/Tiny.pm. Ok.
Description verified from lib/File/Slurp/Tiny.pm. Ok.

TODO: Although the package name indicates what is slurped and spewed, I'd like to see explicit mention in the description that it's about files (content).

License verified from README, LICENSE, lib/File/Slurp/Tiny.pm. Ok.
No XS code, noarch BuildArch is Ok.
Old spec cruft presents for EPEL. Ok.

TODO: Specify versions at Test::Pod* build-requires. (Versions are missing to allow gracious degradation of tests probably.)

Build-requires are Ok.
All tests pass. Ok.

$ rpmlint perl-File-Slurp-Tiny.spec ../SRPMS/perl-File-Slurp-Tiny-0.003-2.fc21.src.rpm ../RPMS/noarch/perl-File-Slurp-Tiny-0.003-2.fc21.noarch.rpm 
perl-File-Slurp-Tiny.src: W: spelling-error Summary(en_US) slurper -> slurped, slur per, slur-per
perl-File-Slurp-Tiny.noarch: W: spelling-error Summary(en_US) slurper -> slurped, slur per, slur-per
2 packages and 1 specfiles checked; 0 errors, 2 warnings.
rpmlint is Ok.

$ rpm -q -lv -p ../RPMS/noarch/perl-File-Slurp-Tiny-0.003-2.fc21.noarch.rpm 
drwxr-xr-x    2 root    root                        0 Feb 26 09:18 /usr/share/doc/perl-File-Slurp-Tiny
-rw-r--r--    1 root    root                      392 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/Changes
-rw-r--r--    1 root    root                    18356 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/LICENSE
-rw-r--r--    1 root    root                      384 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/README
-rw-r--r--    1 root    root                     2704 Feb 26 09:18 /usr/share/man/man3/File::Slurp::Tiny.3pm.gz
drwxr-xr-x    2 root    root                        0 Feb 26 09:18 /usr/share/perl5/vendor_perl/File
drwxr-xr-x    2 root    root                        0 Feb 26 09:18 /usr/share/perl5/vendor_perl/File/Slurp
-rw-r--r--    1 root    root                     4332 Jan 21 00:03 /usr/share/perl5/vendor_perl/File/Slurp/Tiny.pm
File layout and permissions are Ok.

$ rpm -q --requires -p ../RPMS/noarch/perl-File-Slurp-Tiny-0.003-2.fc21.noarch.rpm | sort | uniq -c
      1 perl(Carp)
      1 perl(Exporter) >= 5.57
      1 perl(FileHandle)
      1 perl(File::Spec::Functions)
      1 perl(:MODULE_COMPAT_5.18.2)
      1 perl(strict)
      1 perl(warnings)
      1 rpmlib(CompressedFileNames) <= 3.0.4-1
      1 rpmlib(FileDigests) <= 4.6.0-1
      1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
      1 rpmlib(PayloadIsXz) <= 5.2-1
Binary requires are Ok.

$ rpm -q --provides -p ../RPMS/noarch/perl-File-Slurp-Tiny-0.003-2.fc21.noarch.rpm | sort | uniq -c
      1 perl(File::Slurp::Tiny) = 0.003
      1 perl-File-Slurp-Tiny = 0.003-2.fc21
Binary provides are Ok.

$ resolvedeps rawhide ../RPMS/noarch/perl-File-Slurp-Tiny-0.003-2.fc21.noarch.rpm 
Binary dependencies resolvable. Ok.

Package builds in F21 (http://koji.fedoraproject.org/koji/taskinfo?taskID=6571978). Ok.

Package is in line with Fedora and Perl packaging guidelines.

Resolution: Package APPROVED.

Comment 11 Paul Howarth 2014-02-26 09:20:20 UTC
New Package SCM Request
=======================
Package Name: perl-File-Slurp-Tiny
Short Description: A simple, sane and efficient file slurper
Owners: pghmcfc
Branches: f19 f20 el5 el6 epel7
InitialCC: perl-sig

Thanks for the review Petr. I'll update the %description post-import, and the Pod test module version requirements are indeed omitted to support building on EPEL < 7, where the versions are older than the tests want.

Comment 12 Gwyn Ciesla 2014-02-26 13:05:46 UTC
Git done (by process-git-requests).

Comment 13 Fedora Update System 2014-02-26 15:08:58 UTC
perl-File-Slurp-Tiny-0.003-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-File-Slurp-Tiny-0.003-3.fc19

Comment 14 Fedora Update System 2014-02-26 15:09:13 UTC
perl-File-Slurp-Tiny-0.003-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/perl-File-Slurp-Tiny-0.003-3.el6

Comment 15 Fedora Update System 2014-02-26 15:09:21 UTC
perl-File-Slurp-Tiny-0.003-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-File-Slurp-Tiny-0.003-3.fc20

Comment 16 Fedora Update System 2014-02-26 15:09:31 UTC
perl-File-Slurp-Tiny-0.003-3.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/perl-File-Slurp-Tiny-0.003-3.el5

Comment 17 Fedora Update System 2014-03-09 04:33:30 UTC
perl-File-Slurp-Tiny-0.003-3.fc19 has been pushed to the Fedora 19 stable repository.

Comment 18 Fedora Update System 2014-03-09 04:36:00 UTC
perl-File-Slurp-Tiny-0.003-3.fc20 has been pushed to the Fedora 20 stable repository.

Comment 19 Fedora Update System 2014-03-17 05:58:18 UTC
perl-File-Slurp-Tiny-0.003-3.el5 has been pushed to the Fedora EPEL 5 stable repository.

Comment 20 Fedora Update System 2014-03-17 05:59:59 UTC
perl-File-Slurp-Tiny-0.003-3.el6 has been pushed to the Fedora EPEL 6 stable repository.


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