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

Randy Barlow <ra...@electronsweatshop.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |mgans...@alice.de
              Flags|                            |needinfo?(mgans...@alice.de
                   |                            |)



--- Comment #2 from Randy Barlow <ra...@electronsweatshop.com> ---
Hello!

There are a few issues that will need to be fixed for approval:

* The package can't be installed. dnf reports:

  - nothing provides python-kivy(x86-64) = 1.9.1-2.fc27 needed by
    python-kivy-doc-1.9.1-2.fc27.noarch
  - nothing provides python-kivy(x86-64) = 1.9.1-2.fc27 needed by
    python-kivy-examples-1.9.1-2.fc27.x86_64

  Recommendations:

  - Use the %{?python_provide:%python_provide python2-%{srcname}} and
    %{?python_provide:%python_provide python3-%{srcname}} macros in the
    python2- and python3- subpackages. This will also make python2-kivy provide
    python-kivy as it is currently supposed to do.
  - IMO, example and doc packages don't really need to Require the package they
    document. You could just drop these requires. This is completely at your
    option of course, but if you do so, be sure to add the license file to both
    of them.

* The license on this package is a bit complex according to fedora-review's run
  of licensecheck. I think the License field should be: LGPLv2.1+, GPLv2+,
  GPLv3, BSD, and MIT. Additionally, three of the example files are CC by-nc,
so
  the example subpackage further requires that label.

* The Requires are in the top level of the spec file, and only specify python3-
  requirements. Presumably, the python2- subpackage also needs its versions of
  these dependencies. The way it's specified, neither subpackage gets its
  dependencies when installed.

  Recommendation:

  - Move the python3- dependencies into the python3- %package section, and add
    python2- equivalents into the python2- %package section.


That's all for requirements to be approved, but I have a few suggestions that
are at your option (if you don't do the things after this, it won't block
approval of the package):

* The package bundles some fonts. There are a few ways to deal with this:

  - These fonts are already packaged for Fedora - you could Require: them and
    then symlink them.

  - You can declare that your package has these fonts bundled by using this
    syntax:

    Provides: bundled(dejavu-sans-fonts)
    Provides: bundled(google-roboto-fonts)

  - Delete the fonts - does it really need them?

* There's a newer version of the package available upstream. According to their
  home page, 1.10.0 is released.

* Is it possible to run the test suite in Koji? If so, it would be good to add
  a %check section.

* About 6 MB is being stored in /usr/share. That data could be split into a
  noarch subpackage that the other packages Require:, which would be nice to
do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org

Reply via email to