Bug 35014 - treat undefined macros as errors in more sections
Summary: treat undefined macros as errors in more sections
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build (show other bugs)
Version: unstable
Hardware: all Linux
: P3 enhancement
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-09 16:32 MSK by Ivan Zakharyaschev
Modified: 2018-06-09 16:32 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.