Usage of %{__macros} in our .specs?

[Michael Schwendt]

On Wed, 17 Dec 2008 16:40:14 +0100, Martin wrote:

> Hi all,
> 
> I've been told, by an upstream developer of one of the packages I
> maintain, that I/we should use e.g. %{__make} instead of make in
> our .spec files in order to have our packages more compatible/portable.

That is common misbelief and macro-madness. Not only does it require every
RPM target platform to define all macros, you also need the same
customisability in the upstream tarballs. Every configure script, every
hand-written Makefile fragment, every helper shell-script needs to be
customisable so you could give it the value %__rm expands to instead of
just letting it use "rm" or search PATH.

> As I understand it, if I use make, whatever make is find in the $PATH of
> the user the package is build under, it will be used,

Sufficient.

> however if I use
> %{__make} /usr/bin/make (as per 'rpmbuild --showrc" output) will be used
> regardless of what environment path I've set. It's similar for other
> macros like %{__rm}, %{__sed}, %{__mv} or %{__cp}, %{__ln_s} or
> %{__mkdir_p} to name a few. 

Some don't use absolute paths, see e.g.
  rpm --eval %__awk
  rpm --eval %__cc
  rpm --eval %__cxx
  ...
  rpm --eval %__ln_s
  rpm --eval %__libtoolize
and others.

> I haven't found any guideline regarding this and our packages seem to
> wary in the way they use it. Should there be any guideline or
> recommendation created for it? What do others think about it? 

In ordinary spec sections, use what's in PATH.

Be careful inside the package scriptlets. Only with absolute paths, you
can construct proper dependencies for any executables you run in the
scriptlets. Without absolute paths, you can only require package names,
but executables may move to a different package. Add safety checks
to you package, e.g. in the %prep or %check sections.