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

On Thursday 26 February 2004 5:19 pm, Michael Schwendt wrote: 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