Dne 20. 04. 20 v 12:02 Miro Hrončok napsal(a):
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.fedorapr...
>>
>>
>>
>> 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.
I don't know if it does or doesn't, but I am quite sure that this is not
correct. Dependencies like this should be removed and minimized and not
used as justification. `rpmbuild -bs` should work without as much macros
as possible.
Currently, I have on my computer these `srpm-macros` packages (and also
some others with different names):
```
$ rpm -qa *srpm*
fonts-srpm-macros-2.0.5-1.fc33.noarch
nim-srpm-macros-3-2.fc32.noarch
openblas-srpm-macros-2-7.fc32.noarch
gnat-srpm-macros-4-11.fc32.noarch
rust-srpm-macros-13-2.fc33.noarch
fpc-srpm-macros-1.3-1.fc32.noarch
python-srpm-macros-3.8-2.fc33.noarch
ghc-srpm-macros-1.5.0-2.fc32.noarch
go-srpm-macros-3.0.8-5.fc32.noarch
efi-srpm-macros-4-4.fc32.noarch
ocaml-srpm-macros-6-2.fc32.noarch
perl-srpm-macros-1-34.fc32.noarch
qt5-srpm-macros-5.13.2-2.fc32.noarch
```
I don't remember I would ever need any of them.
Vít
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.