On Thursday 26 February 2004 5:19 pm, Michael Schwendt wrote:
> Again, $RPM_BUILD_ROOT is preferred at fedora.us as long as it is
> described as the "official supported" mechanism on getting access to
> buildroot.
FWIW %{buildroot} and $RPM_BUILD_ROOT are not the same due to the way macros
are processed. IIRC, the build/install scriptlets can modify $RPM_BUILD_ROOT
internally, but, again IIRC %{buildroot} gets the expanded buildroot not as
an environment variable. In fact, a %dump reveals a couple of sets of
definitions (for different uses: $RPM_BUILD_ROOT could vary between
scriptlets depending upon you rpmmacros):
You find in __build_pre:
%{?buildroot:RPM_BUILD_ROOT="%{u2p:%{buildroot}}"
export RPM_BUILD_ROOT}
But in _preScriptEnvironment it's:
%{?buildroot:RPM_BUILD_ROOT="%{buildroot}"
export RPM_BUILD_ROOT
}
meaning that $RPM_BUILD_ROOT is derived from %buildroot.
So the scriptlets cannot mung with the buildroot if you use %{buildroot}, but
you can if you use $RPM_BUILD_ROOT (which means you can fix a bad buildroot
using the envvar). Macro definitions/redefinitions are not part of the
scriptlet, of course (just like C preprocessor directives are not part of the
actual C code).
Now, you CAN mung with %{buildroot} elsewhere, but that's beyond this. You
just can't do it programmatically during build script execution. Some would
say that's a good thing; others would vehemently disagree.
However, if you need to use the value of buildroot in a macro definition you
probably should use %buildroot, a'la %makeinstall (whose definition uses
nearly as many %{buildroot}'s as it does {} pairs). Of course, there are
exceptions to this; as long as you realize that the macro definition is
substituted into the script as a string you can use envvars inside the macro
definition, but the interpretation is up to the host scriptlet. %mdkicons for
instance uses $RPM_BUILD_ROOT inside the macro. But a definition using
%{buildroot} results in the static string that is the buildroot, and using
the envvar results in the envvar, which might not be what it needs to be....
Of course, I do reserve the right to be wrong, but I think I verified this
insome test specs I built up a long time ago.
The point is that the $RPM_BUILD_ROOT recommendation isn't even consistently
followed in the rpmmacros definitions themselves, meaning that every spec
file is using a willy-nilly mix of %{buildroot} and $RPM_BUILD_ROOT even if
those strings do not appear in your spec file itself. Thus the
recommendation and checklist item is totally redundant and really deserves to
be removed, Jeff's comments notwithstanding. If and when Jeff actually
changes ${buildroot} basic core rpm build macros will break, and break badly,
so the likelihood of that change happening is somewhere between slim and
none, and Slim just left town. Of course, Jeff has surprised us
before... :-)
Each have their uses, and the spec file maintainer may intend %{buildroot}
where it is specified; and $RPM_BUILD_ROOT might be better for another. But
it is obvious that %{buildroot} is a little (marginally) easier to type and
read.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
