[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #20 from Fedora Update System upda...@fedoraproject.org --- perl-File-Slurp-Tiny-0.003-3.el6 has been pushed to the Fedora EPEL 6 stable repository. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-File-Slurp-Tiny-0.003- ||3.fc21 Resolution|--- |NEXTRELEASE Last Closed||2014-03-17 02:23:00 -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #19 from Fedora Update System upda...@fedoraproject.org --- perl-File-Slurp-Tiny-0.003-3.el5 has been pushed to the Fedora EPEL 5 stable repository. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #17 from Fedora Update System upda...@fedoraproject.org --- perl-File-Slurp-Tiny-0.003-3.fc19 has been pushed to the Fedora 19 stable repository. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #18 from Fedora Update System upda...@fedoraproject.org --- perl-File-Slurp-Tiny-0.003-3.fc20 has been pushed to the Fedora 20 stable repository. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #10 from Petr Pisar ppi...@redhat.com --- 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-x2 rootroot0 Feb 26 09:18 /usr/share/doc/perl-File-Slurp-Tiny -rw-r--r--1 rootroot 392 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/Changes -rw-r--r--1 rootroot18356 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/LICENSE -rw-r--r--1 rootroot 384 Jan 21 00:03 /usr/share/doc/perl-File-Slurp-Tiny/README -rw-r--r--1 rootroot 2704 Feb 26 09:18 /usr/share/man/man3/File::Slurp::Tiny.3pm.gz drwxr-xr-x2 rootroot0 Feb 26 09:18 /usr/share/perl5/vendor_perl/File drwxr-xr-x2 rootroot0 Feb 26 09:18 /usr/share/perl5/vendor_perl/File/Slurp -rw-r--r--1 rootroot 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. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Paul Howarth p...@city-fan.org changed: What|Removed |Added Flags||fedora-cvs? --- Comment #11 from Paul Howarth p...@city-fan.org --- 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. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? |fedora-cvs+ -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #12 from Jon Ciesla limburg...@gmail.com --- Git done (by process-git-requests). -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #13 from Fedora Update System upda...@fedoraproject.org --- 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 -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|MODIFIED -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #14 from Fedora Update System upda...@fedoraproject.org --- 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 -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #16 from Fedora Update System upda...@fedoraproject.org --- 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 -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #15 from Fedora Update System upda...@fedoraproject.org --- 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 -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
CC||ppi...@redhat.com
--- Comment #8 from Petr Pisar ppi...@redhat.com ---
(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.
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
--- Comment #9 from Ralf Corsepius rc040...@freenet.de ---
(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.
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|nob...@fedoraproject.org|ppi...@redhat.com Flags||fedora-review? -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
--- Comment #6 from Ralf Corsepius rc040...@freenet.de ---
(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.
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995 --- Comment #7 from Christopher Meng cicku...@gmail.com --- Perl6? That's Rakudo so far. -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
--- Comment #5 from Paul Howarth p...@city-fan.org ---
(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.
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
Leon Weber l...@leonweber.de changed:
What|Removed |Added
CC||l...@leonweber.de
--- Comment #1 from Leon Weber l...@leonweber.de ---
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
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
--- Comment #2 from Leon Weber l...@leonweber.de ---
(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 :)
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
--- Comment #3 from Paul Howarth p...@city-fan.org ---
- %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.
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
[Bug 1064995] Review Request: perl-File-Slurp-Tiny - A simple, sane and efficient file slurper
https://bugzilla.redhat.com/show_bug.cgi?id=1064995
Ralf Corsepius rc040...@freenet.de changed:
What|Removed |Added
CC||rc040...@freenet.de
--- Comment #4 from Ralf Corsepius rc040...@freenet.de ---
(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).
--
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
