https://bugzilla.redhat.com/show_bug.cgi?id=2443622
--- Comment #5 from Ben Beasley <[email protected]> --- > - Package contains BR: python2-devel or python3-devel See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_build_time_dependency_on_python3_devel: this requirement may be satisfied by any of: - an explicit, manual BuildRequires: python3-devel - use of %pyproject_buildrequires (c.f. the guidelines link above, as well as https://pagure.io/packaging-committee/pull-request/1384) - use of BuildSystem: pyproject: not explicitly mentioned in the guidelines since the declarative buildsystem remains provisional, but see discussion in https://pagure.io/packaging-committee/pull-request/1379 This package has BuildSystem: pyproject, so an explicit BuildRequires would be redundant. > b) Consider packaging the documentation. Happy to package missing > dependencies, > but not a blocker. As a general rule, I no longer package generated documentation in Python packages. I was once a proponent of doing so, but I’ve slowly come around to the view that the value of generated offline documentation is not worth the complexity, added dependencies, and various issues associated with producing it. HTML documentation has various issues with bundled CSS, JS, fonts, etc. and their licenses. PDF documentation mostly sidesteps these, but can be fussy and brittle, and brings in heavy build dependencies on TeX Live. Your method of building documentation in texinfo format and then converting to Docbook XML is clever, appears to comply with packaging guidelines, and can be useful for those who know what to do with it. However, the result is a somewhat unusual format that people are less likely to discover or know how to read, and which needs close inspection for usefulness since it’s very unlikely to be tested by upstreams, who are in most cases exclusively targeting HTML; and the added spec-file complexity is viable, but not insignificant. Perhaps if there were a distribution-wide consensus that this was “the” way to handle Python documentation, then I might view this format as more worthwhile to produce. > c) Should the name be python-python-discovery? > On Pypi, there are both discovery and python-discovery packages: > https://pypi.org/project/python-discovery/ > https://pypi.org/project/discovery/ In https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_library_naming, the guidelines now explicitly state: > The Fedora component (source package) name for a library should be formed by > taking the canonical project name and prepending python- if it does not > already start with python-. This may leads to conflicts (e.g. between > bugzilla and python-bugzilla). In that case, ensure upstream is aware of the > potentially confusing naming and apply best judgment. Looking at https://pypi.org/project/discovery/#history, it was first released on June 2, 2015, and the final release was just three days later. The GitHub repository linked to by the PyPI page has been removed. It’s clear not only that this now is a dead project, but also that it never really got off the ground in the first place. It’s therefore vanishingly unlikely that the “other discovery package” will ever be submitted to Fedora. Considering this, and the above prescription quoted from the guidelines, I believe that python-discovery is the correct name. -- 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 https://bugzilla.redhat.com/show_bug.cgi?id=2443622 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202443622%23c5 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
