https://bugzilla.redhat.com/show_bug.cgi?id=2263790 --- Comment #30 from Petr Menšík <pemensik@xxxxxxxxxx> --- VCS is used because I modify it manually and want to have VCS present, along with better presentation for end users on pypi. Alternatives path were wrong, fixed it. Spec URL: https://github.com/pemensik/yq/raw/fedora/python-yq.spec SRPM URL: https://pemensik.fedorapeople.org/srpm/python-yq-3.4.3-12.fc41.src.rpm (In reply to Martin Hoyer from comment #29) > Thanks Petr! > Might I suggest starting with `pyp2spec yq --license Apache-2.0`, as there > are some inconsistencies with the reference? For example: > > URL: https://pypi.org/project/yq/ > VCS: git:%{srcforge} > Source0: %{pypi_source yq} > --- > URL: https://github.com/kislyuk/yq > Source: %{pypi_source yq} > > (also it's not srcforge) What is meant by srcforge if github.com is not one of them? > > Other than that: > > BuildRequires: sed > I believe this is redundant > > > Requires(post): %{_bindir}/alternatives > Not saying it's wrong, but `update-alternatives` is being used in the > guidelines - > https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ I have modified it to use just alternatives, because they are real binary, update-alternatives just a symlink. Not sure what variant is actually more preferred, but manual page references just alternatives. That is why I chosen to use that for a new package. But used wrong _bindir path, updated it in place. > > > Patch1: yq-tomlkit-f39.patch > Again, nothing wrong with that, but since there already is sed workaround > for the setuptools_scm, also for F39, why not have two seds instead? Patch is actually more safe, when surrounding lines may change meaning of done change. Also sed itself does not guarantee the change were done successfully, patch does. > > > %{?python_provide:%python_provide python3-%{srcname}} > I believe this is also redundant > > >sed -e 's/^version_file/#write_to/' -i pyproject.toml > Just curious why is write_to commented out It seemed to me this works well in normal mockbuild, but were needed just in my local build attempts. Using shipped part of release seems better than generating anything from fedora distgit. Review targets rawhide, where this is unnecessary. -- 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=2263790 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202263790%23c30 -- _______________________________________________ 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
