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.
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
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.
Dne 6.1.2016 v 22:03 Orion Poplawski napsal(a):
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.
What are these special macros you need to generate SRPM? There shouldn't be any IMO.
Vít
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
On 01/07/2016 05:57 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
> "VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
Not if the macro is evaluated for a BuildRequires line or Exclude/ExclusiveArch, then the resulting src.rpm is incorrect. But for other cases you are correct.
Dne 7.1.2016 v 17:04 Orion Poplawski napsal(a):
On 01/07/2016 05:57 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
>> "VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
Not if the macro is evaluated for a BuildRequires line or Exclude/ExclusiveArch, then the resulting src.rpm is incorrect.
Do you have any convincing examples of such .spec files at hand? I am curious.
Vít
On 01/07/2016 09:41 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 17:04 Orion Poplawski napsal(a):
On 01/07/2016 05:57 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
>>> "VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
Not if the macro is evaluated for a BuildRequires line or Exclude/ExclusiveArch, then the resulting src.rpm is incorrect.
Do you have any convincing examples of such .spec files at hand? I am curious.
http://pkgs.fedoraproject.org/cgit/rpms/python3-setuptools.git/tree/python3-...
python3_pkgversion needs to be defined.
http://pkgs.fedoraproject.org/cgit/rpms/nodejs.git/tree/nodejs.spec
nodejs_arches needs to be defined.
Dne 7.1.2016 v 17:59 Orion Poplawski napsal(a):
On 01/07/2016 09:41 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 17:04 Orion Poplawski napsal(a):
On 01/07/2016 05:57 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
>>>> "VO" == Vít Ondruch vondruch@redhat.com writes:
VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
Not if the macro is evaluated for a BuildRequires line or Exclude/ExclusiveArch, then the resulting src.rpm is incorrect.
Do you have any convincing examples of such .spec files at hand? I am curious.
http://pkgs.fedoraproject.org/cgit/rpms/python3-setuptools.git/tree/python3-...
python3_pkgversion needs to be defined.
I can't see reason, why there shouldn't be:
|BuildRequires: python%{?python3_pkgversion}-devel|
http://pkgs.fedoraproject.org/cgit/rpms/nodejs.git/tree/nodejs.spec
nodejs_arches needs to be defined.
ExclusiveArch for building SRPM? Neither this makes sense. It might just fail a bit faster in Koji, but it is not worth of some special macro package IMO.
Vít
Dne 8.1.2016 v 10:09 Vít Ondruch napsal(a):
Dne 7.1.2016 v 17:59 Orion Poplawski napsal(a):
On 01/07/2016 09:41 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 17:04 Orion Poplawski napsal(a):
On 01/07/2016 05:57 AM, Vít Ondruch wrote:
Dne 7.1.2016 v 11:17 Jason L Tibbitts III napsal(a):
>>>>> "VO" == Vít Ondruch vondruch@redhat.com writes: VO> What are these special macros you need to generate SRPM? There VO> shouldn't be any IMO.
It's not uncommon for a spec to be syntactically invalid if a macro is not defined, which prevents SRPM generation. Rather than including line noise boilerplate in every spec to conditionally define them to nonsense values, or simply defining them there, the macros are added to the buildroot.
If this were done more consistently, we could actually get rid of a significant amount of line noise.
- J<
You can get rid of these macros for SRPM build typically just by replacing %{my_macro} by %{?my_macro}, i.e. adding just single question mark. If you follow this practice, we could get rid of not just significant amount of lines but also of significant amount of -srpm-macros packages and all the noise you now requires just to generate SRPM. Don't forget, that the macros are lazy evaluated, so you don't have to have every possible macro defined when building SRPM.
Vít
Not if the macro is evaluated for a BuildRequires line or Exclude/ExclusiveArch, then the resulting src.rpm is incorrect.
Do you have any convincing examples of such .spec files at hand? I am curious.
http://pkgs.fedoraproject.org/cgit/rpms/python3-setuptools.git/tree/python3-...
python3_pkgversion needs to be defined.
I can't see reason, why there shouldn't be:
|BuildRequires: python%{?python3_pkgversion}-devel|
Actually I might be wrong in this case, since the BR are transformed into R for SRPM. But anyway, I am not sure how (if at all) this information is consumed by our build system. I should probably take a look at "dnf builddep" ...
Vít
||
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> You can get rid of these macros for SRPM build typically just by VO> replacing %{my_macro} by %{?my_macro}, i.e. adding just single VO> question mark.
Some of them, but not all of them. Think of what happens when you do:
BuildRequires: %{py3_versions}
How will conditional evaluation help that?
Yes, we could do %{?py3_dependencies}, and maybe we would, but even then the extra ? notation is odd and easy to miss. I'd like to reduce the need for that kind of thing, not increase it.
Besides, the cost is pretty close to zero (not even any new packages if the files are placed in redhat-rpm-config) so I don't see the need here. I do, however, disagree with the practice of having an unbounded number of packages we have to stuff in the buildroot, each containing one macro file.
In the currently running FPC meeting proposed having fedora-rpm-macros or fedora-rpm-config or something where we can collect these.
- J<
Jason L Tibbitts III wrote:
Besides, the cost is pretty close to zero (not even any new packages if the files are placed in redhat-rpm-config) so I don't see the need here. I do, however, disagree with the practice of having an unbounded number of packages we have to stuff in the buildroot, each containing one macro file.
In the currently running FPC meeting proposed having fedora-rpm-macros or fedora-rpm-config or something where we can collect these.
We had GNAT_arches in redhat-rpm-config for a while. Then we needed to add GPRbuild_arches. Panu didn't want the maintenance burden, so he asked us to move the macros to a separate package. Thus gnat-srpm-macros was created, which has the advantage that we who maintain Ada packages also maintain the relevant macros, so we can update the architecture lists without troubling anyone else.
Would everyone who needs to edit one of these macros be made co-maintainer of the collection package? Or are there people who are willing to make changes on request? Enough such people to always be responsive?
Björn Persson
packaging@lists.fedoraproject.org