Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 191350 - Review Request: perl-Spreadsheet-ParseExcel
Review Request: perl-Spreadsheet-ParseExcel
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
Depends On: 191387
  Show dependency treegraph
Reported: 2006-05-10 21:41 EDT by Michael A. Peters
Modified: 2014-08-11 08:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-08 01:51:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
limburgher: fedora‑cvs+

Attachments (Terms of Use)
e-mail reply from upstream regarding license (2.95 KB, text/plain)
2006-05-11 10:38 EDT, Michael A. Peters
no flags Details

  None (edit)
Description Michael A. Peters 2006-05-10 21:41:24 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.



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.
Comment 1 Michael A. Peters 2006-05-10 23:34:16 EDT
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
Comment 2 Jason Tibbitts 2006-05-11 10:20:11 EDT
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.
Comment 3 Michael A. Peters 2006-05-11 10:36:56 EDT
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.
Comment 4 Michael A. Peters 2006-05-11 10:38:41 EDT
Created attachment 128894 [details]
e-mail reply from upstream regarding license
Comment 5 Michael A. Peters 2006-05-11 11:04:17 EDT
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.
Comment 6 Michael A. Peters 2006-05-15 02:48:02 EDT
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).
Comment 7 Jason Tibbitts 2006-06-02 23:55:55 EDT
rpmlint complains:

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:
   6ee6257d4b66cb9e147a0b50603d1387  Spreadsheet-ParseExcel-0.2603.tar.gz
   6ee6257d4b66cb9e147a0b50603d1387  Spreadsheet-ParseExcel-0.2603.tar.gz-srpm
* 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
   ok 1
* 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.

Comment 8 Michael A. Peters 2006-06-08 01:51:07 EDT
imported, owners list updated, branched, built for FC-4/5 and rawhide
Comment 9 Fabio Alessandro Locati 2014-08-11 05:02:44 EDT
Package Change Request
Package Name: perl-Spreadsheet-ParseExcel
New Branches: epel7
Owners: fale
InitialCC: perl-sig
Comment 10 Petr Šabata 2014-08-11 08:36:22 EDT
I'm okay with Fabio maintaining this in epel7.
Comment 11 Gwyn Ciesla 2014-08-11 08:40:19 EDT
Git done (by process-git-requests).

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