Re: Replacing Vendor rpms.

[Frank Cusack <fcusack fcusack com>]

On September 14, 2006 5:50:12 PM -0700 Steven Hajducko <steven hajducko digitalinsight com> wrote:
> Hi,
>
> In an effort to clean up some of our software installs and upgrade
> applications in the same stroke, I'm trying to compile and build some
> RPMs for various applications.
>
> At this point, I've gotten the build process down where I can actually
> compile/install my RPM, however, I want to get rid of the vendor's RPM
> in the process.
>
> So, for example, we are installing our own compiled openssl-0.9.8c to
> replace the RedHat openssl-0.9.7a rpm on some our systems.  However,
> quite a few of RedHat's other RPM's require 'libcrypto.so.4' and
> 'libssl.so.4', which are just links to the actual shared ssl libs (
> libcrypto.so.0.9.7 and libssl.so.0.9.8 ).

They are not just symlinks.  Well they are, but there's more to it.
The soname of the libraries match the symlink name.  If you just build
0.9.8c without setting the soname like RH, you'll break all apps which
were built against the RH libs.

> In my %install section, I create the links necessary and I have them
> specified in my %files section.  If I do a 'rpm -qpl' on my RPM file, I
> see the libcrypto.so.4 and libssl.so.4 files listed, however, I'm not
> sure how I'm supposed to be able to get my package to actually 'upgrade'
> the current package on the system.  I could just --force, but I want to
> try and keep this as clean as possible.

I assume the problem is that you tried to do 'rpm -U' and it failed.
This is because your new rpm doesn't provide the same libs (sonames)
that the old one did, and some apps depend on it.  To fix it, fix
the soname problem.

But I'd take a step back and ask why you feel you need to change out
the RH rpms.  Your 0.9.8c is almost certainly not "better" than the
RH 0.9.7a in any meaningful way.  RH frequently (and horribly unfortunately)
patches packages to include fixes from newer versions without updating
the version number. As best as I can figure out, they do this because
1) they pull patches from CVS (gotta be on the bleeding edge all the
time, you know, nothing else will do) before packages actually get
a version bump, and/or 2) they generate fixes themselves which later
make it upstream.  In both cases they then fail to keep pace when
the upstream version is bumped, probably to "save" maintenance effort.

Of course if you ARE doing something special (like including IDEA for
use outside the US) then ignore my criticism. :-)

-frank