[KLUG Members] Source RPMs, anyone?

[Adam Williams]

>>Over the last few weeks, I've been involved in several projects that 
>>have required the most recent source RPMs (if anyone is interested in
>>why, I'll be happy to explain, but that's not the direction I care to
>>take in THIS message). Not having them on-hand was a source of some 
>>annoyance and delay in what was going on.

Yes, finding source RPMS, while theoretically easy, is a pain.

>I've used source RPMs only when I couldn't get the binary rpm to work on 
>my system.  Is your preference for source code because it allows for 
>modification of the source code itself or because the process of 
>installing from a source RPM allows you to modify the configuration?

I typically use source rpms to install, edit the spec file, and build
binary rpms.  The spec file contains the call of ./configure
{--blahblah} which is usually what I change.  Many main-stream packages
leave out support for various things, typically like LDAP, Kerberos V,
etc... that I want.  Rebuild a source RPM is better than just building
from tgz as you stay in line with the distribution and avoid having
various libraries populated all over (/lib, /usr/lib, opt/lib, opt/???,
/usr/local/lib) creating a Linux version of DLL hell.  Try installing
the SASL2 rpms on top of a /usr/local TGZ install of SASL2.... Or two
installs of SASL2 tgz that happen to send a couple of files to different
paths than the previous one..... :)  Let the mayhem ensue!  You'll spend
a good day grousing about with ldd, strace, lsof, and the like trying to
figure out what the &^#$* @&*^$*( $ @&*^#$ #$ @!*(&$ is going on.

Also some authors only release TGZs.  But if you can find an SRC.RPM of
an older version it is usually trivial to install the older src.rpm,
replace the tgz in /usr/src/redhat/SOURCES, diddle the spec file just a
bit, and build an RPM of the newer package.

Another reason is that it is pretty trivial to patch-n-build.  Unpack
the tgz in /usr/src/redhat/SOURCES, diddle, and re-pack.  Then build the
RPM.  Handy when you have a useful program but disagree with a design
decision or two,  Directoy Administrator is one example.  The author
treats Person as an addition to posixAccount.  We treat posixAccount as
an addition to Person, so I just path newdruids.c to mod how it
constructs DNs for new objects,  and proliferating the modified program
is still as easy as rpm -Uvh....

BTW, I'd buy a SRCRPM CD at least once every couple of months, at
standard KLUG prices.  More often then I buy a binary RPM CD, as
red-carpet does that for me.