Red Hat Bugzilla – Bug 191350
Review Request: perl-Spreadsheet-ParseExcel
Last modified: 2014-08-11 08:40:19 EDT
Spec file: http://mpeters.us/fc_extras/perl-Spreadsheet-ParseExcel.spec
Src RPM: http://mpeters.us/fc_extras/perl-Spreadsheet-ParseExcel-0.2603-0.1.src.rpm
This module allows you to get information from Excel file.
This module can handle files of Excel95, 97 and 2000. (and now supports Excel4)
The module will work on the majority of Windows, UNIX and Macintosh platforms.
DO NOT APPROVE YET
1) License is listed as Unknown at CPAN and I can not find it in the source.
For that reason, I have set release at 0.1 and am attempting to contact upstream author to get a new release with a license included.
2) Full functionallity for Japanese requires manual installation of a file marked as %doc and requires modification of a file owned by another package.
The module is capable of some additional functionallity if a Unicode::Map file is installed, and the Unicode::Map REGISTRY file is modified.
The location where perl-Unicode-Map puts its .map files looks to be arch dependent.
This is a noarch package, and I would rather not install the .map file into an arch dependent location forcing the package to be arch dependent.
Also - I would rather not modify a file of another package.
Assuming the license issue is resolved, I will file an RFE with perl-Unicode-Map (and cc the Fedora perl list in the RFE) to see if the maintainer of that package is willing to modify that package so that things will "just work".
I would like to submit this package because there is a LaTeX macro on CTAN that can make use of it, that would be useful for importing data from excel format spreadsheets.
Response from upstream:
Thank you for your mail.
And I've selected
"Standard-Perl denotes that the user may choose between GPL and Artistic,"
at my PAUSE (Perl Authors Upload Server) page.
I do not have a PAUSE account, but is this good enough to set license to GPL or
Yes, this is sufficient. However, until the actual sources indicate the
license, I would make sure that the actual message from the author is available
either in the package or attached to this bugzilla ticket so that there's no
room for confusion.
Are you still requesting that reviews be held off? I think it might be
reasonable to disable thie additional functionality that requires the
perl-Unicode-Map modifications until those are in.
OK - I can put the actual message from the author as an attachment.
I would like to hold off on actual review until the Japanese support is figured
out, partly because I think it should be there, and partly because rpm autodeps
will require the additional perl modules that are only needed if set up for
Japanese support, so if the Japanese support isn't there then it has dependency
In the following attachment, I have altered the message to hide the private
e-mail address the upstream author replied from. The public e-mail address
(which is in the package source) is still there.
Created attachment 128894 [details]
e-mail reply from upstream regarding license
Ah geez - the license is there.
It's in ParseExcel.pm
You may distribute under the terms of either the GNU General Public
License or the Artistic License, as specified in the Perl README file.
New spec file and src.rpm:
Ready for review.
I went ahead and made the package arch dependent so that it can install and own
the map file. The japanese support that the map file provides will not work
until bug #191387 is resolved, but when bug #191387 is resolved it should *just
work* (famous last words ...)
The package is arch dependent solely because of the map file.
This causes a completely empty and useless debuginfo package. So I set a macro
in the spec file to not build the debuginfo package.
The license is issue is resolved (GPL or perl).
E: perl-Spreadsheet-ParseExcel no-binary
Unfortunately the package can't be noarch because of the map file, so this is
BuildRequires: perl is not necessary (not a blocker).
The documentation is over half of the size of the package, but the total package
size is small so I don't think it's necessary to place it in a subpackage.
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible. License text not included upstream.
* source files match upstream:
* latest version is being packaged.
O BuildRequires are proper (BR: perl is unnecessary).
* package builds in mock (development, x86_64).
O rpmlint has only ignorable complaints.
* final provides and requires are sane:
perl(Spreadsheet::ParseExcel) = 0.2603
perl(Spreadsheet::ParseExcel::FmtDefault) = 0.05
perl(Spreadsheet::ParseExcel::FmtJapan) = 0.05
perl(Spreadsheet::ParseExcel::FmtJapan2) = 0.05
perl(Spreadsheet::ParseExcel::FmtUnicode) = 0.05
perl(Spreadsheet::ParseExcel::SaveParser) = 0.01
perl(Spreadsheet::ParseExcel::SaveParser::Workbook) = 0.06
perl-Spreadsheet-ParseExcel = 0.2603-1.fc6
* no shared libraries are present.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is present and the single test passes:
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
* no scriptlets present.
* code, not content.
O documentation is relatively small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
imported, owners list updated, branched, built for FC-4/5 and rawhide
Package Change Request
Package Name: perl-Spreadsheet-ParseExcel
New Branches: epel7
I'm okay with Fabio maintaining this in epel7.
Git done (by process-git-requests).