Thanks Bob. This was probably more of a learning experience for me in dealing with libraries and sonames than it was in how RPM actually works. :) The advice is appreciated. I think I'll leave this minetrap alone for now and see what issues I run into when building the RPM's for our own apps. -- sh -----Original Message----- From: rpm-list-bounces@xxxxxxxxxx [mailto:rpm-list-bounces@xxxxxxxxxx] On Behalf Of Bob Proulx Sent: Friday, September 15, 2006 8:41 AM To: rpm-list@xxxxxxxxxx Subject: Re: Replacing Vendor rpms. Steven Hajducko wrote: > The original question still stands ( with more information from Frank > ) > - How do I overwrite the so's for a library that other RPM's are > dependant upon? I think your best course of action would be to leave the old rpm installed and allow it to provide the old functionality. If you want to install a new library providing a new ABI then provide it as an additional rpm that can be installed along side the old one. A common technique is to add the version to the name so that "--upgrade" will not remove the old named rpm. Call yours openssl098c for example. Yes this is a hack but that is basically what you are asking for. Don't overlap with any files from the previous rpm package and yours will be completely independent of it. Personally I would avoid trying to provide critical libraries such as openssl and similar. They high visibility interfaces which often need security upgrades. By using a vendor supplied library you benefit from sharing the work among a team of people. If you do it yourself then you have keep track of issues yourself and jump to it when problems are disclosed or your server may become vulnerable to a crack. Bob _______________________________________________ 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
