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@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. 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. > _______________________________________________ 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
