On 20. 04. 20 9:35, Vít Ondruch wrote:
Dne 19. 04. 20 v 16:55 Miro Hrončok napsal(a):
Hello Python packagers.
After touching the %python_provide topic in:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje...
I have realized several things I don't like about %python_provide:
- It must be used conditionally (it is not defined in
python-srpm-macros). That means you always wrap it in %{?python_provide:...} in order to have a "valid" specfile even when the macro is not yet defined (e.g. during SRPM creation in Koji or on a packager's machine without python-rpm-macros installed).
This is an advantage. People does not need to have installed python-srpm-macros just to build SRPM, when they are using Mock or Koji to build the package. Please keep it this way.
What you say is not true.
redhat-rpm-config requires python-srpm-macros.
People already do need to have redhat-rpm-config (and hence python-srpm-macros) installed when they are using Mock or Koji to build the package. They even need it when they use `rpmbuild -bs`.
I'm keeping it that way.
python-srpm-macros contain macros that are essential to make building SRPM work. There is no external dependency brought in by python-srpm-macros, just the macros. Currently, it has:
%__python{,2,3} %python{,2,3} %python3_pkgversion %__python_other %py3_other_{build,install} (that does not need to be in srpm macros) %py_dist_name %py{2,3}_dist %pypi_source
Do you suggest that the need for "python-srpm-macros is always guaranteed to be there" is artificial? The following (quite extensively used) constructs would not be possible:
Source0: %{pypi_source} BuildRequires: %{python3} // or the more widespread older %{__python3} BuildRequires: %{py3_dist sphinx} BuildRequires: python%{python3_pkgversion}-pytest
Whether or not that is "an advantage" is very much out of scope of what I have proposed. You might argue that by adding one more macro to python-srpm-macros and by using it unconditionally, I am cementing the status quo. However I consider the status quo cemented beyond point of return. Hundreds of Perl, Go, Haskell, Rust etc. packages (there are 13 *-srpm-macros packages required by redhat-rpm-config) won't build SRPMs correctly if this guarantee is gone. All the packages would need to be adapted to different constructs, often throwing away "magic" and going back to "boilerplate" (see e.g. %gometa).
I won't fight you discussing whether this is good or bad, but your feedback is not relevant in this thread.