pam src rpm replaced?

[Mike A. Harris]

On Sun, 24 Aug 2003, Joel Young wrote:

>> 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.


Because we're developing Red Hat Linux on Red Hat Linux FOR Red 
Hat Linux, and we're testing those packages on Red Hat Linux 
only.  Such macros are almost never useful in Linux OS's 
themselves, and they add a large amount of complicated looking 
ugliness to spec files.

While this may inconvenience a solaris user trying to compile one 
of my src.rpms on solaris, um... sorry, but I'm not trying to 
make RPM packages that build on solaris.  You'll be very hard 
pressed to find rpm packages in any distribution that compile 
without modification on non-Linux systems.

You'll also be unlikely to find Solaris packages that work 
without modification on Linux.

There's no incentive to do extra work like that when it slows 
down development, and gives you zero benefit and you have zero 
way of testing it, and end up with an ugly looking spec file that 
is mostly unreadable.

That is why.

>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 :-)

No, by all means, feel free to vent your frustrations.  Just 
realize that there isn't any incentive or real benefits to 
developers of any Linux distribution (or external packagers) in 
trying to make their packages build on 10000 operating systems 
they don't have access to.

Does XFree86.spec compile on Solaris/sparc?  No idea.  Don't 
care, and I'd reject/delete any patch sent to me that made it 
actually work as it would be non-useful to me as a developer, non 
useful to Red Hat, and non useful to our users.

I will however bet that it is easier for a Solaris RPM packager 
dude to take my src.rpm and free of cost to them, be able to 
modify it to build on solaris.  I'll even bet that my work would 
have saved them countless hours of time, and that they'll be 
thankful they had something to start with instead of writing one 
from scratch.  Ditto for other packages.  ;o)

You'll be hard pressed to find many developers out there who
favour making their packages unreadable for other OS's IMHO.  
It's often hard enough to just make a single src.rpm package 
build on more than one Linux distribution.

But I digress...


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat