Re: python-macros review

[Vít Ondruch <vondruch@xxxxxxxxxx>]

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@xxxxxxxxxx> 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-setuptools.spec?h=epel7

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

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx