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 <cweyl@xxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cweyl@xxxxxxxxxxxxxxx AssignedTo|nobody@xxxxxxxxxxxxxxxxx |cweyl@xxxxxxxxxxxxxxx --- Comment #3 from Chris Weyl <cweyl@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review