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.
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"...
Ok, thanks for the explanation. Should this bug be closed as NOTABUG or do you plan to do something related to this?
Moving this to upstream tracking so the issue wont go completely forgotten but no immediate plans: http://rpm.org/ticket/842