Bug 35014

Summary: treat undefined macros as errors in more sections
Product: Sisyphus Reporter: Ivan Zakharyaschev <imz>
Component: rpm-buildAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P3 CC: arseny, glebfm, imz, ldv, placeholder, vt
Version: unstable   
Hardware: all   
OS: Linux   

Description Ivan Zakharyaschev 2018-06-09 16:32:10 MSK
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.