On September 14, 2006 5:50:12 PM -0700 Steven Hajducko <steven.hajducko@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
