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.
http://pkgs.fedoraproject.org/cgit/rpms/nodejs.git/tree/nodejs.spec
nodejs_arches needs to be defined.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion@xxxxxxxx
Boulder, CO 80301 http://www.nwra.com
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
