Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 177276

Summary: Review Request: perl-DBD-AnyData : DBI access to XML, CSV and other formats
Product: [Fedora] Fedora Reporter: Tom "spot" Callaway <tcallawa>
Component: Package ReviewAssignee: Jason Tibbitts <j>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-extras-list
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-09 23:53:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 177275    
Bug Blocks: 163779, 177277    

Description Tom "spot" Callaway 2006-01-08 18:30:43 UTC
Spec Name or Url: http://www.auroralinux.org/people/spot/review/perl-DBD-AnyData.spec
SRPM Name or Url: http://www.auroralinux.org/people/spot/review/perl-DBD-AnyData-0.08-1.src.rpm
Description: 
DBI access to XML, CSV and other formats

This package is a new BuildRequires for perl-Class-DBI-AbstractSearch.

Comment 1 Orion Poplawski 2006-02-15 23:31:14 UTC

- I like long descriptions.  Some or all of:

The DBD::AnyData module provides a DBI/SQL interface to data in many
formats and from many sources.

Currently supported formats include general format flatfiles (CSV, Fixed
Length, Tab or Pipe "delimited", etc.), specific formats (passwd files,
web logs, etc.), a variety of other kinds of formats (XML, Mp3, HTML tables),
and, for some operations, any DBI accessible database. The number of
supported formats will continue to grow rapidly since there is an open API
making it easy for any author to create additional format parsers which can
be plugged in to AnyData.

Data in these various formats can come from local files, from remote files,
or from perl data structures such as strings and arrays.

Regardless of the format or source of the data, it may be accessed and/or
modified using all standard DBI methods and a subset of SQL syntax.

In addition to standard database access to files, the module also supports
in-memory tables which allow you to create temporary views; to combine data
from a number of sources; to quickly prototype database systems; and to
display or save the data in any of the supported formats (e.g. to display
data in a CSV file as an HTML table). These in-memory tables can be created
from any combination of DBI databases or files of any format. They may also
be created from perl data structures which means it's possible to quickly
prototype a database system without any file access or rdbms backend.

The module also supports converting files between any of the supported
formats (e.g. save selected data from MySQL or Oracle to an XML file).



Comment 2 Jason Tibbitts 2006-02-21 05:05:47 UTC
Since this seems to be a requirement for bug 177277, I'll review this as well.

First off, I agree with Orion.  Mostly.  It's not really necessary to write a
book, but

%description
%{summary}.

doesn't really work.  Please at least give a couple of sentences of description.
Also, as in 177277, the BuildRequires: perl >= 1:5.6.1 is pointless and needs to
go and %build should be:

%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
make %{?_smp_mflags}

unless the package breaks.


Comment 3 Ville Skyttä 2006-02-21 05:32:53 UTC
(In reply to comment #2)
> %build should be:
> %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"

There's no need to use OPTIMIZE="$RPM_OPT_FLAGS" for noarch packages.


Comment 4 Jason Tibbitts 2006-02-21 14:23:05 UTC
Of course you're correct; there's no need to use %{?_smp_mflags} for a package
with a single perl file either.   But sticklers complain about deviations from
the template and I've had a couple of my reviews being second guessed lately,
leading me to think that I'm being too lenient in not pointing out such deviations.

Comment 5 Tom "spot" Callaway 2006-04-01 05:51:52 UTC
New SPEC: http://www.auroralinux.org/people/spot/review/perl-DBD-AnyData.spec
New SRPM:
http://www.auroralinux.org/people/spot/review/perl-DBD-AnyData-0.08-2.src.rpm

Note that I didn't OPTIMIZE a noarch package because it is utterly pointless.

Comment 6 Jason Tibbitts 2006-04-07 19:37:53 UTC
Sorry for taking so long to get back to this.

The package builds in mock on FC-5 and devel, and rpmlint is happy.  %check
throws several errors of the form:

DBI handle 0xa4c9e38 cleared whilst still active at test.pl line 39.
    dbih_clearcom (sth 0xa4c9e38, com 0xa59b458, imp DBD::AnyData::st):
       FLAGS 0x182115: COMSET Active Warn PrintError PrintWarn ShowErrorStatement
       PARENT DBI::db=HASH(0xa0c98d4)
       KIDS 0 (0 Active)
       IMP_DATA undef
       NUM_OF_FIELDS 3
       NUM_OF_PARAMS 0

which doesn't effect the build but might we worth looking into if they would
appear in actual use.

* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written, uses macros consistently and
conforms to the Perl template.
* license field matches the actual license.
* license is open source-compatible.  It's not included separately in the
package, but this is not necessary.
* source files match upstream:
   3434afdade1e2c9d79e85eca4bd8df17  DBD-AnyData-0.08.tar.gz
   3434afdade1e2c9d79e85eca4bd8df17  DBD-AnyData-0.08.tar.gz-save
   a23f31a0eb908ce5b5468bd2d4e44744  perl-DBD-AnyData.spec
* package builds in mock.
* BuildRequires are proper.
* no shared libraries are present.
* package is not relocatable.
* package does not create any directories (besides %doc) and only uses
directories created by its dependencies.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* code, not content.
* documentation is 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.
* Package owns no files that are owned by other packages.

APPROVED

Comment 7 Tom "spot" Callaway 2006-04-09 23:53:16 UTC
Built in repo.