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 - rpmbuild doesn't set certain macros when using %{with ...} constructs
Summary: rpmbuild doesn't set certain macros when using %{with ...} constructs
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-23 09:49 UTC by Nils Philippsen
Modified: 2009-05-18 09:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-05-18 09:58:09 UTC

Attachments (Terms of Use)
spec file which exhibits the broken behavior (deleted)
2008-07-23 09:49 UTC, Nils Philippsen
no flags Details
spec file which works around the broken behavior (deleted)
2008-07-23 09:50 UTC, Nils Philippsen
no flags Details

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):

How reproducible:

Steps to Reproduce:
1. rpmbuild -bp broken.spec
Actual results:
+ echo %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

%{!?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

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

    %{!?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...)

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