On 01/06/2016 10:21 AM, Vít Ondruch wrote:
Dne 30.12.2015 v 23:13 Orion Poplawski napsal(a):
On 12/30/2015 02:48 PM, Neal Gompa wrote:
On Wed, Dec 30, 2015 at 3:46 PM, Orion Poplawski orion@cora.nwra.com wrote:
I've submitted a review for a separate python-macros package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1294904
This is what the FPC approved here https://fedorahosted.org/fpc/ticket/567#comment:12 to be added to the Fedora buildroots to provide the %python3_pkgversion macro needed for compatibility with the EPEL Python3 packaging guidelines.
It also serves the much more important goal of getting the python macros out of the the individual python? packages to make it easier to update them.
Don't we normally name these something to the effect of "<name>-srpm-macros"? For example, we have "go-srpm-macros" and "perl-srpm-macros". Shouldn't this be named "python-srpm-macros" for consistency purposes?
I guess you're right, though we have a mix at the moment:
blender-rpm-macros.noarch 1:2.76-2.fc24 rawhide erlang-rpm-macros.noarch 0.1.4-2.fc23 rawhide ghc-rpm-macros.x86_64 1.4.15-3.fc23 rawhide ghc-srpm-macros.noarch 1.4.2-2.fc23 rawhide gnat-srpm-macros.noarch 2-1.fc23 rawhide go-srpm-macros.noarch 2-3.fc24 rawhide kde-apps-rpm-macros.noarch 6:4.14.15-3.fc24 rawhide kernel-rpm-macros.noarch 36-1.fc24 rawhide kf5-rpm-macros.noarch 5.17.0-2.fc24 rawhide ocaml-srpm-macros.noarch 2-3.fc23 rawhide perl-srpm-macros.noarch 1-17.fc23 rawhide
And some just "-macros":
perl-macros.x86_64 4:5.22.1-355.fc24 koji python-macros.noarch 2.7.11-1.fc24 koji python3-pkgversion-macros.noarch 1-5.fc24 koji sip-macros.noarch 4.17-3.fc24 koji
But it does look like it is the *-srpm-macros that tend to be in the buildroot.
And we have rubygem-devel and ruby-devel shipping some macros. I can hardly understand why the packages should be in separate pacakge and why there should be (s)rpm or macros mentioned.
Vít
For normal, general use rpm macros I see no reason not to have them in a -devel package, or perhaps -rpm-macros if there is no -devel package.
But it actually does strike me as appropriate to put only those macros needed for generating srpms into a -srpm-macros package which redhat-rpm-config then requires in order to get it into the buildroot, which seems to be the main current convention.