pam src rpm replaced?

[Joel Young]

--------
From: "Mike A. Harris" <mharris at redhat.com>
> On Sun, 24 Aug 2003, Michael Schwendt wrote:
> 
> >package, every tool which is needed to build a src.rpm would not be
> >found unless it is a buildreq or a dependency of a package which is
> >installed already. Sort of a minimal installation of Red Hat Linux
> >with only rpm-build and its dependencies installed. Every additional
> >package required to build a src.rpm would need to be an explicit
> >BuildRequires in the src.rpm.
> 
> That sounds sensible.  If you find packages missing such 
> dependancies, please file them in bugzilla.

As someone who maintained a 460 package rpm set up providing gnome and
kde and a lot of other stuff install for Solaris using packages drawn
from redhat, mandrake, pld, suse, ximian, I found the use of build tools in
packages to be highly frustrating.  Package builders routinely hard
coded paths to external programs or just let them default to whatever one
was first in path.  This creates chaos on a solaris system if a non gnu
version is found for some esoteric build requirement.  I ended up
creating/customizing a large set of macros allowing these to be specified
explicitly.  e.g.

%__patch                /pro/gnome/bin/patch
%__perl                 /pro/gnome/bin/perl
%__pgp                  %{_pgpbin}
%__rm                   /pro/gnome/bin/rm
%__rsh                  /bin/rsh
%__sed                  /pro/gnome/bin/sed
%__ssh                  /usr/local/bin/ssh
%__lex                  /pro/gnome/bin/flex

included from basedir/lib/rpm/macros

The frustrating thing was even for redhat packages, these macros
provided in the redhat provided rpm package weren't used 
religiously in redhat spec files.  Anytime a spec developer
calls an external routine, they should consider creating a macro
in lib/rpm/macros if it doesn't exist already.  If he decides
not to create one, he should consider defining a macro a the top
of his package and also having a build dependency.

Sorry for soapbox.  Just venting an old frustration.  Since I no longer
am no longer maintaining this mass of .spec files, it isn't so important
to me any more :-)

Joel