https://bugzilla.redhat.com/show_bug.cgi?id=2112474 --- Comment #23 from John Snow <jsnow@xxxxxxxxxx> --- (In reply to Maxwell G from comment #20) > Some more comments: Thank you for your time and feedback, I appreciate it. My current goal is to fix as much as I can and ensure there are no more changes that might need to be made for v0.0.2 upstream to make this spec file workable. As I go, I'm learning a lot about the tooling and process so please pardon the temporary slowness. > > > Cleber Rosa (upstream maintainer for avocado-framework) tells me that fedora:latest carries a stream wherein avocado is kept at the bleeding edge, but that a non-modular package cannot rely upon a modular one as a dep. > > Yup, the implementation of modularity is... not the best. > > > He is working on updating the normal package from Avocado LTS 82.0 to Avocado LTS 92.0, which will unblock me here. > > That major version bump will only be able to happen in branched (f37) and > rawhide (f38) according to the Updates Policy[1]. > > [1]: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ > I think that's likely fine. QEMU 7.2 is the first candidate for needing this package, and that isn't expected until Nov/Dec. > Keep in mind that you won't be able to push incompatible updates to this > package in stable updates, either. Given that this is an alpha package, > you'll have to take that into consideration. Understood! (You called it an alpha package -- is that because you read my readme?) > > (people.redhat.com has an expired SSL cert. You might want to report that > internally...) Seems to have been fixed: "Not Before Wed, 10 Aug 2022 00:00:00 GMT" > > > The specfile looks good for the most part. > > You need to include the license file and mark it with %license in %files for > both subpackages. Oops. Lost these in an edit. Re-added in my working draft, thank you. > > ``` > %files -n python3-%{pkg_name} -f %{pyproject_files} > %doc README.rst > %license LICENSE LICENSE_GPL2 > [...] > > %files -n python3-%{pkg_name}-doc > %license LICENSE LICENSE_GPL2 > %doc html > ``` > > You should preserve the description for both subpackages and name the doc > subpackage as `python-qemu-qmp-doc`. You can change > > ``` > %package -n python3-%{pkg_name}-doc > Summary: Documentation for %{pkg_name} > %description -n python3-%{pkg_name}-doc > Documentation for %{pkg_name} > ``` > > to > > ``` > %package doc > Summary: Documentation for %{pkg_name} > > %description -n python3-%{pkg_name}-doc %_description > > This package provides documentation for python3-qemu-qmp. > ``` > > You'll also need to change `%files -n python3-qemu-qmp-doc` to `%files doc`. Ah, I see. OK, I've mostly implemented your suggestion, but I did spell out "python-qemu-qmp-doc" explicitly instead. (No strong reason, I guess I liked the visual parity? Will change if desired.) Is it common to reproduce the same description for the doc package? I picked a few at random and it didn't seem that way, but I did it anyway. > > More nitpicky comments: > > Consider removing *_name macros as discussed. I've done so in my working copy. I almost argued for keeping pypi_name, but I then found this blurb concerning pypi_source on the packaging guidelines: "For backward compatibility, the first argument is technically optional as well, but omitting it is deprecated. (It defaults to %srcname if defined, or to %pypi_name if defined, or to %name.)" So, I dropped both. > > > rm %{buildroot}%{_bindir}/qmp-tui > > I'm not a fan of this. Fedora packages should try to stay close to upstream > projects[1], and this feels like a deviation from that. I'm happy to help > you split it out into a subpackage if needed. However, if you still maintain > that this shouldn't be packaged, I won't push hard on it. > > [1]: > https://docs.fedoraproject.org/en-US/package-maintainers/ > Staying_Close_to_Upstream_Projects/ Understood. Currently, the TUI requires some packages that Fedora does not yet package. I'm reluctant to split out another Python package for QEMU before I'm fully finished with the first, so I think it's going to be a while before it's in fighting shape to bother splitting, packaging, documenting, etc. That said, it's there now, certainly -- would you find it preferable to just leave the script entry point installed, ignore missing manpage warnings, and allow the script to simply always return an error [1] ? On the other hand, and with regards to not violating user's expectations that upstream and downstream are not materially different, I've not documented or publicized this script via the docs [2], so I don't anticipate anyone will come looking for it here, so to speak. It was always intended as something you'd get when installing "qemu.qmp[tui]", not "qemu.qmp". And for right now, we only really need the core bits of the library to satisfy the QEMU build dependency. (I originally thought you could guard console script shims using extras, but have since learned that you cannot. I know this means that upstream it really ought to go into its own PyPI package, but I'm not ready for that just yet, for a few organizational reasons that need to be settled in qemu.git patches over the coming months. I will work towards eliminating the discrepancy eventually, some time prior to v1.0.) [1] https://gitlab.com/qemu-project/python-qemu-qmp/-/blob/main/qemu/qmp/qmp_tui.py#L40 [2] https://qemu.readthedocs.io/projects/python-qemu-qmp/en/latest/ Other items: - I tested my current draft with tests added alongside Cleber's new avocado build for f38. It works, but the avocado packages aren't properly ready/available yet. - gpgverify works, but I am using a temporary URL for the keyring during review here. Working on a better home for it. - I have patches upstream for manpage generation; that'll be for 0.0.2, which may as well be the first version we package anyway. In the interest of sharing my progress so you have something to look at: A draft specfile *without* manpages or the avocado dependency (It should work today as-is): https://people.redhat.com/~jsnow/v3a/python-qemu-qmp.spec A draft specfile based on what will be 0.0.2, with manpages and the avocado dependency (It won't work today as-is, but might be useful for critique): https://people.redhat.com/~jsnow/v3b/python-qemu-qmp.spec -- 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=2112474 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
