This is a simple document-oriented interface to a SQLite database, modelled
after Scraperwiki's Python dumptruck module. It allows for easy (and maybe
inefficient) storage and retrieval of structured data to and from a
database without interfacing with SQL.
License is correct.
Add the following BRs
builds successfully in rawhide http://koji.fedoraproject.org/koji/taskinfo?taskID=7194336
rpmlint returns spelling warnings which may be disregarded.
package NOT approved. Resubmit with BRs added.
Thank you for the review.
(In reply to David Dick from comment #1)
> License is correct.
> Add the following BRs
> BR perl(strict)
> BR perl(warnings)
> BR perl(utf8)
> BR perl(B)
Why would I do that? These are part of Perl core.
Because modules move in and out of the perl core at the discretion of the porters. If we (fedora packagers) explicitly describe all the modules we rely on, this prevents build failures later on, when a once core module has been moved out of core.
(In reply to David Dick from comment #3)
> Because modules move in and out of the perl core at the discretion of the
> porters. If we (fedora packagers) explicitly describe all the modules we
> rely on, this prevents build failures later on, when a once core module has
> been moved out of core.
Well, with the modules in questions this is non-realistic. Even if it were, the package can be adjusted then, avoiding BR noise at this point.
I'm quite reluctant to add those unless there's a guideline that would mandate me to do so.
No problems. I'll let someone else review this package then.
Do we still have any updated guidelines for having all the BuildRequires specified in perl module specs? I see some of you are recommending to have all such buildtime requirement added to the spec file. As I see its still not in the Perl packaging guidelines, there should not be any issue to approve such packages.
- Good license
- Sane spec
- Builds and installs correctly
- rpmlint happy
Regarding the BRs - I think this shouldn't block the review and the maintainer can easily fix this if needed.
(In reply to Parag AN(पराग) from comment #6)
> Do we still have any updated guidelines for having all the BuildRequires
> specified in perl module specs? I see some of you are recommending to have
> all such buildtime requirement added to the spec file. As I see its still
> not in the Perl packaging guidelines, there should not be any issue to
> approve such packages.
FWIW, at https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl#Perl_Requires_and_Provides
the following quotation can be obtained;
It is recommended to buildrequire core modules explicitly, because they can move between sub-packages or disappear from core perl.
From looking at the history page, it looks like this page hasn't been modified since 2010.
So according to the guidelines i should have approved the review, given that the wording is "recommended" not "mandatory".
New Package SCM Request
Package Name: perl-Database-DumpTruck
Short Description: Relaxing interface to SQLite
Upstream URL: http://search.cpan.org/dist/Database-DumpTruck/
Owners: lkundrak jtaylor
Branches: f19 f20 f21 el6 epel7
The guidelines haven't been updated as the Perl SIG hasn't reached concensus on how to handle this yet. Sadly, whenever brought up, the disucssion gets stalled pretty quickly.
Indeed, BR'ing not yet dual-lived core modules is optional. Of course, this just means more work as both the packager and the reviewer need to check whether a) the module is currently in core and b) the module isn't dual-lived in Fedora. This needs to be done for all the Fedora releases the package is intended to be in and not just for the review but continuously during the package's lifetime.
I'd drop META.json from %doc.
Git done (by process-git-requests).
Imported and built.