pam src rpm replaced?

[Joel Young]

--------
From: "Mike A. Harris" <mharris at redhat.com>

> On Sun, 24 Aug 2003, Joel Young wrote:
> >explicitly.  e.g.
> > ...
> >%__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.  

I understand that.

> Such macros are almost never useful in Linux OS's 
> themselves, and they add a large amount of complicated looking 
> ugliness to spec files.

%{__lex} is uglier than /usr/bin/flex ?  Do you ever ever ever
test rpms with alternate roots?  Suppose the flex you wanted to use for
the build wasn't in the default location, but instead in your alternate
build root?  Wouldn't it be nice to not have a custom spec?

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

Agreed 100% for redhat developers.

> You'll be very hard pressed to find rpm packages in any distribution
> that compile without modification on non-Linux systems.

You might be surprised.  Perhaps 30 percent build with no modification,
most with trivial modification.

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

Then why did redhat include all of the default %{__xxxx} macros in the
first place?  Why did they make relocatable packages?  Why are the 
things like sysconfdir etc. configurable?  Because it was and is 
useful to redhat I would suppose?  And I would also suppose that 
having the discipline of using them makes things easier internally
to redhat in the long run?  Just supposition on my part tho.

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

I see benefit at least to external packagers.  External packagers
presumably would like their packages to build easily on at least
multiple rpm based linux distros.  The more they use the spec file
macro system, the easier that is.

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

Guaranteed :-)  Maybe thousands of hours saved across 460 packages :-)
And you know, redhat and polish linux packages were by far the easiest
to port because their spec files had the most discipline.

Joel