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@xxxxxxxxxxxxxxxxxxxxxxx/thread/SSJLPWSGFGPYRSHXQZDR7JNQXSDGGX3Z/
I have realized several things I don't like about %python_provide:
1) 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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
