Bug 35014 - treat undefined macros as errors in more sections
: treat undefined macros as errors in more sections
Status: NEW
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2018-06-09 16:32 by
Modified: 2018-06-09 16:32 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2018-06-09 16:32:10
rpm-build-4.0.4-alt111.x86_64

When someone uses an undefined macro in %build, this is usually an error.

Now it is just a warning.

Sometimes, the % signs are to be passed verbatim. Sometimes, they are even to
be used to generate rpm directives (say, sed generating a %files section).
These cases can be fixed.

There are not so many packages with these warnings:

[imz@team success]$ fgrep 'warning: Macro %' -slr . | wc -l
257
[imz@team success]$ pwd
/beehive/logs/Sisyphus-x86_64/latest/success

Here is a related discussion of this feature (but not about turning on errors
for %build): http://lists.rpm.org/pipermail/rpm-maint/2013-February/003383.html

More details about the motivation: if I use a (new) macro in a spec (as the
author), I want that other people when trying to build the package either get
an explicit error (if they don't have the definition of this macro) or build
correctly (if this macro is defined for them already).

Now I need to worry whether it will always be built correctly.

Putting BuildPreReq on a specific release of rpm-build is a way which I don't
like because the definitions in question can be cherry-picked, so there is no
fixed release number which guarantees the presence of this macro definition.