Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=460867


Chris Weyl <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]
         AssignedTo|[EMAIL PROTECTED]    |[EMAIL PROTECTED]




--- Comment #3 from Chris Weyl <[EMAIL PROTECTED]>  2008-09-07 07:15:06 EDT ---
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=811675

=====> perl-ORLite-0.10-1.fc9.noarch.rpm <=====
====> rpmlint
perl-ORLite.noarch: E: description-line-too-long SQLite is a light weight
single file SQL database that provides an excellent platform
perl-ORLite.noarch: E: description-line-too-long for embedded storage of
structured data. However, while it is superficially similar to
perl-ORLite.noarch: E: description-line-too-long a regular server-side SQL
database, SQLite has some significant attributes that make using
perl-ORLite.noarch: E: description-line-too-long it like a traditional database
difficult. For example, SQLite is extremely fast to connect
perl-ORLite.noarch: E: description-line-too-long to compared to server
databases (1000 connections per second is not unknown) and is
perl-ORLite.noarch: E: description-line-too-long particularly bad at
concurrency, as it can only lock transactions at a database-wide level.
perl-ORLite.noarch: E: description-line-too-long This role as a superfast
internal data store can clash with the roles and designs of
perl-ORLite.noarch: E: description-line-too-long traditional object-relational
modules like Class::DBI or DBIx::Class. What this situation
perl-ORLite.noarch: E: description-line-too-long would seem to need is an
object-relation system that is designed specifically for SQLite
perl-ORLite.noarch: E: description-line-too-long and is aligned with its
idiosyncracies. ORLite is an object-relation system specifically
perl-ORLite.noarch: E: description-line-too-long for SQLite that follows many
of the same principles as the ::Tiny series of modules and
1 packages and 0 specfiles checked; 11 errors, 0 warnings.
====> provides for perl-ORLite-0.10-1.fc9.noarch.rpm
perl(ORLite) = 0.10
perl-ORLite = 0.10-1.fc9
====> requires for perl-ORLite-0.10-1.fc9.noarch.rpm
perl >= 0:5.006
perl(:MODULE_COMPAT_5.10.0)  
perl(Carp)  
perl(DBD::SQLite) >= 1.14
perl(DBI)  
perl(DBI) >= 1.58
perl(File::Spec)  
perl(File::Temp)  
perl(Params::Util)  
perl(Params::Util) >= 0.33
perl(strict)  
perl(vars)

rpmlint isn't happy at the long lines in %description; refactoring these to be
< 80 char long should do the trick.

Also, there are two duplicate requires, both caused by explicit requires in the
spec as well as auto-detected ones.  Are those two requires in the spec really
needed?

Aside from that, everything else looks kosher; fix those two things and I'll
approve.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review

Reply via email to