pam src rpm replaced?

[Mike A. Harris]

On Sun, 24 Aug 2003, Joel Young wrote:

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

Yes, it is.  But I wouldn't use either.  I'd use "flex" as it is 
in the path.


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

Locally, my packages are built for testing purposes and 
development in a custom RPM configuration downloadable from my 
ftp "hacks" dir on people.redhat.com.  It basically builds 
everything under ~/rpmbuild

In the Red Hat buildsystem, things are built in chrooted 
buildroots, also with customized rpm configuration, some of it 
via macro files and some via commandline options IIRC.

We test what we plan on shipping.  We don't test if things 
compile on Solaris or any other OS, nor do we care, or have 
reason to care.


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

Then we agree.


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

Perhaps via luck at best.  Hardly due to people going out of 
their way to make them build like that.


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

To allow people who wanted those features the ability to use 
them, in their OWN rpm packages.  ie: 3rd party software 
developers/packagers who wanted those features for their own 
software.

>Why did they make relocatable packages?

Ditto.  3rd party software developers/packagers who wanted those
features for their own software.


>Why are the things like sysconfdir etc. configurable?  Because
>it was and is useful to redhat I would suppose?

Exactly.  Those are defined via macros so that when you're using 
a buildroot, your packages get installed into the fake buildroot 
(really misnamed "installroot") aka. RPM_BUILD_ROOT, instead of 
overwriting files on your actual running operating system during 
%install.

When you use %configure, it gets passed the values of all of 
those variables automatically, so that the autoconfized package 
installs to RPM_BUILD_ROOT not /

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

I don't see the point you're trying to make here.  RPM has tonnes 
of features.  Some were added by Red Hat because they enhanced 
rpm in ways that make creating and maintaining RPM packages 
easier, some enhancements were contributed by other Linux 
vendors, some enhancements were contributed by users of other 
operating systems.  RPM, while used in Red Hat Linux, and 
initially created by Red Hat, is a tool which is portable to many 
operating systems, and used by developers of many operating 
systems to package software for those operating systems.

While RPM "the tool" is portable, that doesn't mean that every 
developer out there in the wild, nor every developer of a given 
operating system should spend half their time trying to make sure 
their actual RPM packages compile and run on 10000 different 
OS's.

Many of the features added to RPM were for the benefit of others 
who wanted those features for other OS's, not for Red Hat to 
personally use in Red Hat Linux, or even care about.  IMHO.


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

By all means, feel free to create src.rpm packages that compile 
and install on every operating system to which RPM is available 
for.  It's all open source.  Feel free to spend as much time as 
you like doing this work, and feel free to distribute the results 
of your labours via ftp/http/apt/yum/etc. to as many people as 
you like, running as many operating systems as you like.

As far as I'm concerned personally for any RPM package I maintain
inside or outside Red Hat Linux, my goal is to make a given
package compile and install and work properly on Red Hat Linux.  
I don't care if the package compiles or installs on any other
Linux distribution, or if it compiles or installs on any other
operating system.  Life is short, and my priorities are getting
more work done that is personally useful to me, to Red Hat, and
to Red Hat users.  I really don't care if my packages ever work
on Solaris to be honest, and I doubt you'll find any large
percentage of RPM packagers out there who feel differently.


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

There you go.


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