Description of problem:

Spec files written for rpm-4.4 (F9) do not work seamlessly with rpm-4.6 (F10) and vice-versa.  This break in compatibility is unnecessary and it should be the case the spec files are interchangeable between these rpm versions.  If spec files cannot be made to be compatible, then there should be an api with the spec file for determining compatibility (version-specific macro etc.).

* the build root (%buildroot, BuildRoot) is handled incompatibly between the two rpm versions.

In rpm-4.4, the BuildRoot can be specified in the spec file, or it can be overridden using the commandline or using a supplemental macro file.

In rpm-4.6, the buildroot can be specified in the spec file, and the Fedora packaging guilelines indicate that it is "deprecated".  It's actually worse than this:

1. rpm-4.6 computes its own value of %_buildrootdir and %buildroot before it reads the spec file.  It doesn't include spec file macros like %name in its computation.  It creates some of the intervening directories (like %_buildrootdir) before starting.

2. rpm-4.6 then reads the BuildRoot: value from the spec file, and uses that for the rest of the rpm build.  The result is two (or three, if the %_buildrootdir macro is untouched) directories created during the build.

3. If BuildRoot: is "deprecated", then this implies that it's not needed in the spec file.  This breaks spec files for rpm-4.4.  Many existing spec files depend on a non-default BuildRoot and $RPM_BUILD_ROOT during the build process.

* AFAICT, many of the same issues exist for %_builddir.  rpmbuild for rpm-4.6 computes this value independent of the spec file, so common idioms of using %name, %version, et al in computing a local build directory don't work for rpm-4.6.

* There is no well-defined way for spec files to detect under which version of rpm they are running.  That is, there is no "rpm api" macro that the spec file can test.  If you grovel through the rpm-4.4 and rpm-4.6 macro files, you can glean details like '%_package_version' and '%_urlhelper' that can (today) be used to identify the version differences, but this is admittedly a hack, and won't likely stand the test of time.

One workaround I did find for BuildRoot: is

  BuildRoot: %{?buildroot}%{!?buildroot:%{_tmppath}/some-build-root}

but why should I have to go back and change all of my spec files?  This hack also doesn't prevent the BUILDROOT (%_buildrootdir) directory from being created every time I run rpmbuild.

* If it's not desirable to make rpm-4.6 backwards-compatible with rpm-4.4 spec files, then I would recommend several usability enhancements:

1. rpmbuild for rpm-4.6 should print a warning (error?) if it detects an incompatible BuildRoot (that is, %buildroot != BuildRoot).

2. rpmbuild for rpm-4.6 should print a warning (error?) if it can't expand macros in %buildroot or %_builddir.

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

rpm-4.4.2.3 (F9)
rpm-4.6.0 (F10)

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: