[Bug 672205] Review Request: pynag - Python Nagios plugin and configuration environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--- Comment #14 from Jason Tibbitts <tibbs@xxxxxxxxxxx> 2012-05-07 19:28:36 EDT ---
I am very sorry for taking so long to get back to this, but here's a review.

Builds fine and rpmlint is silent.  Unfortunately there are a few problems:

Your package is noarch; there is no reason to define python_sitearch since you
won't ever reference that macro.

The code is not GPLv2.  For example, Model/EventHandlers/__init__.py and
Model/macros.py are GPLv3+.  The other code doesn't appear to even have any
license statements; setup.py just says "GPL" and the LICENSE file explicitly
says that if the code doesn't state a version, you can use any version you
like.  So upstream (which I guess means you) really needs to clarify that.  It
would be best to follow the GPL itself for that, since it tells you what to
include in your source files, but at minimum you need to state somewhere what
version of the GPL is in use.

When we see differing licenses on code we always wonder if the code comes from
another project altogether, which would run afoul of
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries.  I'm not sure if
that's the case since the copyright holder seems to be a committer on the
project.  But if that's the case then the project seems to be a bit confused as
to which license is supposed to be on its code, which raises other questions.

You should not in general have Requires: python; rpm should figure that out for
itself.

You don't usually want to add compressed manpages; rpm will compress them
properly using whatever compression method happens  to be preferred.  I guess
upstream provides them compressed for some odd reason so there's not much you
can do unless you want to uncompress them in the spec, which seems kind of
pointless.

There is no need to duplicate all of the documentation in the -examples
package.  It has a dependency on the main package so all of that documentation
is guaranteed to be available.

The -examples package includes a README file which should be documentation.


* source files match upstream.  sha256sum:
  93d971e6f162d4bdaea6ab2735e9dbed1348d4bd64927e9bb1cb5fcca6dc2a54
   pynag-0.4.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summaries are OK.
* descriptions are OK.
* dist tag is present.
X license field does not appear to match the actual license.
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint is silent.
X final provides:
  pynag-0.4-4.fc18.noarch.rpm
   pynag = 0.4-4.fc18
  =
   /usr/bin/python  
X  python >= 2.3
   python(abi) = 2.7

  pynag-examples-0.4-4.fc18.noarch.rpm
   pynag-examples = 0.4-4.fc18
  =
   /usr/bin/python  
   pynag  

? There might be bundled libraries.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X documentation is duplicated between main and -examples packages.
* 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.

-- 
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.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]