Bug 2431166

Spec sanity: The spec is perfectly sane, thank you! :)


Diff sanity against python-roman-numerals-py.

-Name:           python-roman-numerals-py
-Version:        3.1.0
+Name:           python-roman-numerals
+Version:        4.1.0

Obviously good.

-Source:         %{pypi_source roman_numerals_py}
+Source:         %{pypi_source roman_numerals}

Same here.

+BuildRequires:  python3-pytest

This surprised me; the specfile no longer uses the [test] extra for this. Upstream still has it, and only "pytest>=9" is in it, so I suppose this is a way to avoid the >=9 part? I do not entirely like it this way, although it is arguably much simpler than patching the version pin. Perhaps add a comment above the requirement? (Something along the lines of: Upstream has the [test] extra, but it needlessly declares the minimal pytest version and depends on nothing else.)

-%package -n     python3-roman-numerals-py
+%package -n     python3-roman-numerals
 Summary:        %{summary}
 
-%description -n python3-roman-numerals-py %_description
+Provides:       python3-roman-numerals-py = %{version}-%{release}
+Obsoletes:      python3-roman-numerals-py < 3.1.0-7
+
+%description -n python3-roman-numerals %_description
 

Obvious renames.
Please use %py_provides instead of Provides, so it also provides python-roman-numerals-py and python3.14-roman-numerals-py (it also removes the need to specify the version to provide).
Considering the version difference, perhaps Obsolete < 4~~, so if by any chance a hotfix 3.1.1 is released (unlikely), and we update to it in Fedora 43, this Obsoletes does not need to be updated.


 %prep
-%autosetup -p1 -n roman_numerals_py-%{version}
+%autosetup -p1 -n roman_numerals-%{version}

Obvious. 
 
 %generate_buildrequires
-%pyproject_buildrequires -x test
+%pyproject_buildrequires
 
Already addressed above.

-%files -n python3-roman-numerals-py -f %{pyproject_files}
+%files -n python3-roman-numerals -f %{pyproject_files}

Obvious.

---

Note: As this package installs a roman_numerals module, it should normally Conflict with the older one, but considering it Obsoletes it, all is good.

Technically, we could choose not to provide/obsolete and instead keep the old one packaged as upstream does, with a versioned requirement on the new one (see the metadata of https://pypi.org/project/roman-numerals-py/4.1.0/ -- but that would be a pain to keep forever. In Fedora, it's only sphinx that requires this, so if this is firstly built together with the sphinx update, it should be fine.

Note that if you ship this right before the Sphinx update, to allow CI testing the Sphinx update itself, it should be fine, as this does not provide python3dist(roman-numerals-py), python3.14dist(roman-numerals-py). Or you can do it properly via a side tag, but then you cannot really CI test Sphinx. Up to you.


Package APPROVED. Consider keeping the git history of python-roman-numerals-py when you request the repo (fedpkg request-repo --no-initial-commit).

I should have probably at least verify this does build and install before approving it. Let's do that by a PR when you have the repo?

I am distracted. I stated my concerns, but APPROVED the package anyway :D

The concerns that should be addressed upon importing:

- Use %py_provides instead of Provides, so it also provides python-roman-numerals-py and python3.14-roman-numerals-py (it also removes the need to specify the version to provide).
- Considering the version difference, please Obsolete < 4~~, so if by any chance a hotfix 3.1.1 is released (unlikely), and we update to it in Fedora 43, this Obsoletes does not need to be updated.
- Add a comment above the pytest requirement.

The Pagure repository was created at https://src.fedoraproject.org/rpms/python-roman-numerals

PR for initial import: https://src.fedoraproject.org/rpms/python-roman-numerals/pull-request/1