Thanks Frank. I should probably rewind a bit more. I was in the process of creating a some new LDAP servers to replace our rather ancient ones. As an experiement ( and a learning experience ), I figured I'd grab the latest OpenLDAP source and try to build/package it for deployment through our WebJob ( http://webjob.sourceforge.net ) servers. But, I needed a bunch of other prereq's ( openssl, berkleydb, etc ). The only reason I picked OpenSSL for my example is that it was the first one I've tried to build. ( For sake of discussion, the OpenSSL package we currently have is from RH 4.0 EL Update 3 ) When doing the 'rpm -U', it only complained about libcrypto.so.4 and libssl.so.4 As in: libssl.so.4 is needed by (installed) nmap-3.70-1.i386 So, upon investigation and finding it was ( and now have been told it isn't that simple ) a simple symlink, I figured the package dependencies where designed around the symlink as the dependency so that upgrades to the actual .so's were easy enough to implement. I checked against it with that I thought would verify that: ldd /usr/bin/nmap libssl.so.4 => /lib/libssl.so.4 (0x006ea000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x06cf2000) Again, it looked like ( to me and my limited knowledge ), that simply changing the .so behind the curtain ( so to speak ) would allow nmap and the various other programs to link in the newer SSL libraries upon runtime. Unfortunately, I guess that isn't the case and I apologize for not exactly understanding when you state "The soname of the libraries match the symlink name". And yeah, I totally agree with you that nothing about my RPM of openssl-0.9.8c is any better than RH's RPM of openssl-0.9.7k or any other packaged openssl version > 0.9.7, but I was using it more as a learning experience than anything and when I couldn't understand the semantics behind why the upgrade wouldn't take place ( after all, I WAS providing the file RPM was complaining about :D Gosh! ), I figured that in the future when I do have to create RPM's for applications ( proprietary and otherwise ) and if I ever run into this same issue, I would know what to do. :) -- sh -----Original Message----- From: rpm-list-bounces@xxxxxxxxxx [mailto:rpm-list-bounces@xxxxxxxxxx] On Behalf Of Frank Cusack Sent: Thursday, September 14, 2006 6:26 PM To: RPM Package Manager Subject: Re: Replacing Vendor rpms. 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 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
