Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 593363 - %global %(...) expansion issue without BuildArch set
Summary: %global %(...) expansion issue without BuildArch set
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 589705
TreeView+ depends on / blocked
 
Reported: 2010-05-18 15:50 UTC by Ville Skyttä
Modified: 2011-05-25 13:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-25 13:02:57 UTC
Type: ---


Attachments (Terms of Use)
Reproducer specfile (216 bytes, text/plain)
2010-05-18 15:50 UTC, Ville Skyttä
no flags Details

Description Ville Skyttä 2010-05-18 15:50:31 UTC
Created attachment 414897 [details]
Reproducer specfile

There seems to be something weird with (not/partially) expanding %global %(...) when there's no BuildArch set in a specfile.

"rpm -q --qf="%{release}\n" --specfile ~/test.spec" on the attached specfile outputs "test" when the BuildArch is commented out, but "est" when the BuildArch is uncommented.  I'd expect it to always output "est".

This is just a minimal sample for reproducing the issue, real ones can be experienced with some of rpmdevtools' spec templates with rpmbuild; they don't work as intended when there is no BuildArch in the specfile due to similar expansion issue.  This happens with rpm-4.8.0-14.fc13.x86_64 on F-13 as well as rpm-4.4.2.3-18.el5 on CentOS 5.

Comment 1 Panu Matilainen 2010-05-19 06:22:01 UTC
This is, err, "expected" behavior: the two things going on here are 
1) %global is expanded at define time, unlike %define which is expanded when referenced
2) specs without buildarch(s) are parsed just once, but spec with buildarch(s) are parsed "recursively" as many times as there are buildarchs set.

In the reproducer spec, %{name} isn't defined at the time %global foo "executes", so foo gets defined as "%{name}" literally (as the sed doesn't find anything to change there), and thus release gets set to "test" as per %{name} from %{foo}.

When the spec defines buildarch (eg noarch), the first round of spec parsing goes as above, but when the spec is parsed again with the target arch from buildarch(s), %{name} macro is still defined from the first round, so the %global does what you expect it to do.

If you move the %global after Name in the spec, it'll work consistently. Or use %define to get lazy expansion. The realm of rpm macros isn't as straightforward as the Fedora guideline "use %global everywhere"...

Comment 2 Ville Skyttä 2010-05-19 20:24:13 UTC
Ok, thanks for the explanation.  Should this bug be closed as NOTABUG or do you plan to do something related to this?

Comment 3 Panu Matilainen 2011-05-25 13:02:57 UTC
Moving this to upstream tracking so the issue wont go completely forgotten but no immediate plans: http://rpm.org/ticket/842


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