Bug 1123268 - Review Request: perl-Database-DumpTruck - Relaxing interface to SQLite
Summary: Review Request: perl-Database-DumpTruck - Relaxing interface to SQLite
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Marko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-25 08:06 UTC by Lubomir Rintel
Modified: 2016-02-01 02:23 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 16:31:43 UTC
rmarko: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Lubomir Rintel 2014-07-25 08:06:34 UTC
SPEC: http://v3.sk/~lkundrak/SPECS/perl-Database-DumpTruck.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/perl-Database-DumpTruck-1.2-1.fc21.src.rpm

Description:

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.

Comment 1 David Dick 2014-07-25 09:26:08 UTC
License is correct.

Add the following BRs

BR perl(strict)
BR perl(warnings)
BR perl(utf8)
BR perl(B)

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.

Comment 2 Lubomir Rintel 2014-07-25 09:31:58 UTC
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.

Comment 3 David Dick 2014-07-25 10:40:32 UTC
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.

Comment 4 Lubomir Rintel 2014-07-25 11:39:36 UTC
(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.

Comment 5 David Dick 2014-07-25 11:47:18 UTC
No problems.  I'll let someone else review this package then.

Comment 6 Parag AN(पराग) 2014-07-26 07:03:39 UTC
Petr,
   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.

Comment 7 Richard Marko 2014-07-26 08:00:58 UTC
- Good license
- Sane spec
- Builds and installs correctly
- rpmlint happy

ACK.

Regarding the BRs - I think this shouldn't block the review and the maintainer can easily fix this if needed.

Comment 8 David Dick 2014-07-27 07:15:22 UTC
(In reply to Parag AN(पराग) from comment #6)
> Petr,
>    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.

Hi Parag,

FWIW, at https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl#Perl_Requires_and_Provides
the following quotation can be obtained;

<quote>
It is recommended to buildrequire core modules explicitly, because they can move between sub-packages or disappear from core perl. 
</quote>

From looking at the history page, it looks like this page hasn't been modified since 2010.

Comment 9 David Dick 2014-07-27 07:25:48 UTC
So according to the guidelines i should have approved the review, given that the wording is "recommended" not "mandatory".

Comment 10 Lubomir Rintel 2014-07-28 08:28:14 UTC
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

Comment 11 Petr Šabata 2014-07-28 12:16:29 UTC
Parag,

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.

David,

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.

Lubomir,

I'd drop META.json from %doc.

Comment 12 Gwyn Ciesla 2014-07-28 12:18:54 UTC
Git done (by process-git-requests).

Comment 13 Lubomir Rintel 2015-02-11 16:31:43 UTC
Imported and built.

Thank you!


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