[Bug 429882] Review Request: python-Levenshtein - Levenshtein distance measurement library in C

bugzilla at redhat.com bugzilla at redhat.com
Tue Oct 21 04:09:30 UTC 2008


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=429882


Jason Tibbitts <tibbs at math.uh.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
               Flag|                            |fedora-review?




--- Comment #14 from Jason Tibbitts <tibbs at math.uh.edu>  2008-10-21 00:09:28 EDT ---
The odd permissions error doesn't need fixing; it's not your problem.  I only
mention it because it is produced by rpmlint and anyone who builds the package
and checks the output of rpmlint can potentially see the complaint (no matter
how bogus) and may expect to see it addressed in the review.

Packaging code from a dead upstream poses a particular problem.  If there's
really no upstream web site to refer to then it would make sense to specify no
URL tag, or to continue to refer to the old location (in the hope that it will
come back), but in either case it would be beneficial to add an explanatory
comment to the spec.

The same goes for the Source1: URL; if there's no authoritative source for that
file then you'll need to add a comment to that effect.  I'm guessing that the
Source: URL is just pointing at your project's sourceforge site, and that
you're just mirroring the dead upstream site.  Or are you taking over
maintenance of the code?

The real concern with a dead upstream is ongoing maintenance and specifically
security issues.  I don't see much possibility for security vulnerabilities in
this code, but you never know, and if upstream is dead then the burden falls
entirely on you, the maintainer, to deal with issues of that nature.  Anyway,
it's up to you and I'm sure you're aware; I'm just making sure that it gets
said at some point before the package is in the distro.

So basically the spec just needs a little bit of commenting about the state of
upstream and the lack of a download location for Source1:.  My checklist
follows; since there's not really any upstream, several of my usual checklist
items will be missing.

* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   Levenshtein.so()(64bit)
   python-Levenshtein = 0.10.1-5.fc10
   python-Levenshtein(x86-64) = 0.10.1-5.fc10
  =
   libpython2.5.so.1.0()(64bit)
   python(abi) = 2.5

* %check is not present; no test suite upstream.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

-- 
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.




More information about the package-review mailing list