$RPM_BUILD_ROOT != %{buildroot} (was:Re: Prelink success story :))

[Lamar Owen]

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