[lug] passing config parameters to autoconf during .src.rpm rebuild

[Alan Robertson]

Sean Reifschneider wrote:
> On Sat, Aug 17, 2002 at 07:26:35PM -0600, Alan Robertson wrote:
> 
>>My rpms, by contrast, are configured by configure.  These type of RPMs 
>>annoy Rob Riggs ;-).  Hi Rob!
>>
> 
> They also annoy Sean, and I say for good reason.  It sounds like you're
> doing something that at least makes the resulting SRPM duplicate the values
> you entered.  However, an SRPM isn't generated by a --rebuild...

I was hoping for some discussion ;-)

> In my RPMs, I set the user-replacable parts at the top, so the build can
> easily be customized for a few things.  You can also define things from the
> command-line by telling the command-line to evaluate "%define xflags
> --with-user=ups", for example, then:
> 
>    ./configure %{xflags}
> 
> I really don't like this though, because the resulting SRPM, if you do an
> "rpm --rebuild" on it won't produce the same output.

??  Either I don't understand what you're saying, or this isn't true...  The 
spec file is generated by the configure process...

OK... Let me see if I can explain this better...

To make a .src.rpm from source, do one of these:

	./configure foo-options
	make rpm
OR:
	./bootstrap foo-options
	make rpm
OR
	./ConfigureMe rpm

and you'll get src and binary RPMS out of the process.

Once you have a source RPM in your hands, then just do an rpm --rebuild, and 
whatever the person who made your RPM chose for configure flags will get 
propagated into the binary RPM.  No matter what they put into the configure 
options, they propagate into the .src.rpm, and subsequently into the 
generated binary RPMs.

And they stay there through any number of --rebuilds.

Here's the magic line in heartbeat.spec.in:

	./configure @ac_configure_args@

Autoconf replaces the @ac_configure_args@ with whatever arguments it was 
given.  Then, those arguments become part of the .src.rpm.

As a side benefit, this method can do *anything* with the RPM, including 
things you can't do with RPM macros.

 > Therefore, you have
> to remember what options you used to build the code last time, and are kind
> of circumventing one of the benefits that RPM gives you: reproducability.

It's always reproducible.  And it's always flexible.  And you don't have to 
write anything down as long as you don't lose your RPMs.

Once you make that first src RPM, you don't have to remember anything.

If you did something custom, then the next time you make a src RPM from the 
source, then you'll need to know what you did last time.  To find out what 
you did last time, look in your previous generation RPM and see what flags 
you used (they'll be there in the specfile).

If you don't ever want to have to figure anything out or remember anything, 
run the ConfigureMe script.  And, it works correctly on multiple distros 
(basically every RPM-based distro) without any changes.  The same cannot be 
said for a normal RPM.

If you have custom options that you want set for KRUD, we'll gladly put them 
in the ConfigureMe script.

Here's the relevant function from ConfigureMe().
---------------------------------------
ConfigureLinux() {
   DFLAGS=""
   if
     [ -f /etc/UnitedLinux-release -a -s /etc/UnitedLinux-release ]
   then
     distro=UL
     PACKAGECMD="make rpm"
     DFLAGS="--with-ucd-snmp-devel=ucdsnmp --with-group-id=90 
--with-ccmuser-id=90"
   elif
     [ -f /etc/SuSE-release -a -s /etc/SuSE-release ]
   then
     distro=SuSE
     PACKAGECMD="make rpm"
     DFLAGS="--with-ucd-snmp-devel=ucdsnmp --with-group-id=90 
--with-ccmuser-id=90"
   elif
     [ -f /etc/redhat-release -a -s /etc/redhat-release ]
   then
     distro=RedHat
     PACKAGECMD="make rpm"
   elif
     [ -f /etc/conectiva-release -a -s /etc/conectiva-release ]
   then
     distro=Conectiva
     PACKAGECMD="make rpm"
     DFLAGS="--with-group-id=17 --mandir=/usr/share/man 
--infodir=/usr/share/info --with-ccmuser-id=17"
   else
     distro="Generic"
   fi
   CFENV="$distro Linux"
   FLAGS="--prefix=/usr --sysconfdir=/etc --localstatedir=/var $DFLAGS"
}
-------------------------------------

Patches are being accepted  ;-)

This scheme is capable of building non-RPM packages, and also handling 
non-Linux OSes.  And, ignorant users who are running on various distros 
don't have to know anything.  The distro-specific knowledge is in the build 
process.


	-- Alan Robertson
	   alanr at unix.sh