Bug 1259678

Summary: %filter_setup breaks custom macros defined inside spec file
Product: Red Hat Enterprise Linux 6 Reporter: Assen Totin <assen>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.7CC: lkardos
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-16 13:28:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proof-of-concept spec file none

Description Assen Totin 2015-09-03 10:49:54 UTC
Created attachment 1069745 [details]
proof-of-concept spec file

Description of problem:
The %filter_setup macro in a spec file undefines any custom macro which was defined inside the spec file before the filter is run. If the macro originated on the command line, it will survive properly and will not gen undefined. 

Version-Release number of selected component (if applicable):
rpm-build-4.8.0-38

How reproducible:
Every time

Steps to Reproduce:
1. Create a spec file. Conditionally define a macro (i.e. define it with a default value if it was not defined on command line):
%{!?_example_macro:%define _example_macro example}

2. After this definition create a filter to udate the RPM metadata and call the %filter_setup macro to enable it. 

3. Build an RPM from the spec file without defining the custom macro on the command line.

Actual results:
After the %filter_setup is run, the macro is undefined. 

Expected results:
The macro stay defined after of %filter_setup runs.

Additional info:
An example spec file is attached.

If a macro is defined on command line with --define 'macro value', then %filter_setup will not touch it and it will properly expand in any subsequent section of the spec file (%install, %files etc.). However, if you do not define the macro on the command line and rely on its default value, %filter_setup will kill it, so the macro will only be defined from the point of defnition to the point where %filter_setup is run. Since the filter is usually defined and applied before %description, this makes the macro unavailable in any subsequent section (%prep, %build, %install, %files...)

When filter is not used, the default value for a macro works as expected (i.e. if macro is not defined on the command line, it gets defined inside the spec file with the specified value and properly expands throughout the spec file).

My current workaround is to move the %filter_setup before any default value definition for an undefined macro. However, this is not a fix and also breaks certain policies (e.g., EPEL guidelines).

Same issue is also present in Fedora, e.g. with rpm-build-4.12.0.1-7.fc21.

Comment 2 Ľuboš Kardoš 2015-09-16 13:28:34 UTC
You have to replace %define with %global in %{!?_example_macro:%define _example_macro example}

Have a look at [1][2].

It is possible to modify current behaviour in such a way that %define would be treated as locally scoped only within parametrized macros as suggested in [3] but if we want to do that, I prefer to do that in upstream first.

[1] http://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html
[2] https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#.25global_preferred_over_.25define
[3] https://bugzilla.redhat.com/show_bug.cgi?id=552944#c8