Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 456389

Summary: rpmbuild doesn't set certain macros when using %{with ...} constructs
Product: [Fedora] Fedora Reporter: Nils Philippsen <nphilipp>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: jnovy, n3npq, pnasrat, yersinia.spiros
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-18 09:58:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
spec file which exhibits the broken behavior
none
spec file which works around the broken behavior none

Description Nils Philippsen 2008-07-23 09:49:32 UTC
Description of problem:
When using constructs like "%if %{with ...}", rpmbuild doesn't expand constructs
like these (perhaps it assumes the macros are already set):

%{!?some_macro: %define some_macro ...}

Version-Release number of selected component (if applicable):
rpm-build-4.4.2.3-2.fc9.x86_64

How reproducible:
Always

Steps to Reproduce:
1. rpmbuild -bp broken.spec
  
Actual results:
[...]
+ echo %some_macro
%some_macro
[...]

Expected results:
[...]
+ echo this works
this works
[...]

Additional info:
I'll attach two spec files, "broken.spec" to demonstrate the problem using this
construct:

%{!?some_macro: %define some_macro this works}

... and "works.spec" which works around the problem using this construct:

%if %{undefined some_macro}
%define some_macro this works
%endif

Comment 1 Nils Philippsen 2008-07-23 09:49:32 UTC
Created attachment 312437 [details]
spec file which exhibits the broken behavior

Comment 2 Nils Philippsen 2008-07-23 09:50:05 UTC
Created attachment 312439 [details]
spec file which works around the broken behavior

Comment 3 Florian Festi 2008-07-28 10:21:31 UTC
Did this example ever work or is it just broken in recent rpm version?

Comment 4 Jeff Johnson 2008-08-03 20:41:08 UTC
Try

    %{!?some_macro: %global some_macro ...}

Comment 5 Nils Philippsen 2008-08-04 10:12:48 UTC
Is this another workaround or are there errors in the attached spec file (and this is the correct way to do it)?

Comment 6 Jeff Johnson 2008-08-04 11:36:07 UTC
All depends on POV.

If using %global rather than %define "works", the issue
is a fundamental design flaw with macros that can't ever
be corrected. The  cure would be far worse than
the disease.

Much like automatic stack storage in C, macros have a scoping level,
and are automatically undefined when they go out of scope.

%global rather than %define within a %{!?test:...} expression sets
the macro at level 0 rather than at level 1.

In most cases the difference between %global and %define doesn't matter.
But the problem shows up from time to time.

There's a bugzilla report from Axel abt 2 years ago last time I recall
the issue being reported. The issue is described fully there.

Does using %global rather than %define fix your issue or not?

Comment 7 Nils Philippsen 2008-08-04 14:18:48 UTC
Interesting background -- and using %global instead of %define indeed works. If this is really unfixable, I can live with using %global as a workaround. We should just update the Python Packaging documentation in the Fedora wiki accordingly.

Comment 8 Jeff Johnson 2008-08-04 14:27:28 UTC
AFAIK, using %global rather than %define is already suggested somewhere deep
in the bowels of the Fedora packaging wiki, added as a side effect of Axel's
bug report 2 years ago.

Changing %define to be a synonym for %global could be attempte.
But that change is most definitely a feature regression that can/will subtly break
parameterized macros and more. Without explicit conformance & regression
tests for macro behavior, that's a really risky change. Which is why I never attempted
a fix.

(aside) Note that there's another fundamental design flaw in macros, passing expanded
(or not) macros as arguments to %foo() parameterized macros. The expectation is
that the expansion, not the unexpanded macro expression, is passed but in fact
the arguments to parameterized macros are unexpanded. One can add explicit
%{expand:...} constructs to solve the issue if necessary. But the behavior is flawed imho.

Comment 9 Panu Matilainen 2009-05-18 09:58:09 UTC
Yup, rpm is behaving as intended, even if not necessarily as expected :)
Fedora documenation now recommends %global over %define (but misses out some other details...)