Bug 456389 - rpmbuild doesn't set certain macros when using %{with ...} constructs
Summary: rpmbuild doesn't set certain macros when using %{with ...} constructs
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2009-05-18 09:58:09 UTC
Type: ---


Attachments (Terms of Use)
spec file which exhibits the broken behavior (414 bytes, text/plain)
2008-07-23 09:49 UTC, Nils Philippsen
no flags Details
spec file which works around the broken behavior (432 bytes, text/plain)
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):
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...)


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