create directories after evaluting spec file macros

[Jeff Johnson]

Tracker

[James (james-redhat-bugs)]

Created attachment 436681
rpm-4.7.2-reorder-spec-eval.patch

Description of problem:

I use macros that are defined in the spec file for rpm directory location, for example:

%_rpmtopdir %{_topdir}/%{name}/%{version}-%{release}

This is fine for rpm -i, but rpmbuild builds the directories before evaluating the spec file, so ~/rpmbuild directory has this:

[james@xavier rpmbuild]$ ls %\{name\}/
%{version}-%{release}

And, when building an rpm I get this:

$ rpmbuild -bp rpm.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.SHLyud
+ umask 022
+ cd /home/james/rpmbuild/rpm/4.7.2-3.spec_first.fc12/work
/var/tmp/rpm-tmp.SHLyud: line 23: cd: /home/james/rpmbuild/rpm/4.7.2-3.spec_first.fc12/work: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.SHLyud (%prep)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.SHLyud (%prep)

Version-Release number of selected component (if applicable):

rpm-4.7.2-2.fc12.x86_64

I know I filed in 13, but the bug is present there as well

How reproducible:

Always

Steps to Reproduce:
1. rpm -i *.src.rpm
2. rpmbuild -bp *.spec
3. errors

Actual results:

$ rpmbuild -bp rpm.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.SHLyud
+ umask 022
+ cd /home/james/rpmbuild/rpm/4.7.2-3.spec_first.fc12/work
/var/tmp/rpm-tmp.SHLyud: line 23: cd: /home/james/rpmbuild/rpm/4.7.2-3.spec_first.fc12/work: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.SHLyud (%prep)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.SHLyud (%prep)

Expected results:

rpmbuild unpacks rpm

Additional info:

Patch attached

[James (james-redhat-bugs)]

All the patch does is reorder so that directory creation happens after spec file evaluation.

[Panu (panu-redhat-bugs)]

As discussed on rpm-maint some time ago, the little "all it does" actually breaks other use-cases, including two tests in the rpm test-suite -> NAK. rpm-maint list is a better place for upstream patch submissions + discussions than Fedora bugzilla anyway.