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
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
(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 :)
> - %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.
(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).
(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.
(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.
Perl6? That's Rakudo so far.
(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.
(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.
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.
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.
Git done (by process-git-requests).
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
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
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
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
perl-File-Slurp-Tiny-0.003-3.fc19 has been pushed to the Fedora 19 stable repository.
perl-File-Slurp-Tiny-0.003-3.fc20 has been pushed to the Fedora 20 stable repository.
perl-File-Slurp-Tiny-0.003-3.el5 has been pushed to the Fedora EPEL 5 stable repository.
perl-File-Slurp-Tiny-0.003-3.el6 has been pushed to the Fedora EPEL 6 stable repository.