That's an interesting idea I'll check it out, thanks. On 6/26/07, Peter Smith <Peter.Smith@xxxxxxxxxxxxxxxxxx> wrote:
Have you given any thought to using the "Obsoletes" tag? I wonder if this is the solution to the problem? Or, have you already come up with one? I was looking carefully at a page that has *some* info which includes it [1]. Peter [1] http://annvix.org/Documentation/Dev/Building/Specs >>> "Xavier Toth" <txtoth@xxxxxxxxx> 06/23/07 9:27 AM >>> I agree that this will work but I was hoping for a solution that wouldn't require this drastic of measures. In my case I've got 80 other packages that are affected and the idea of having to uninstall and reinstall all of them is not nice to put it mildly. On 6/22/07, Hiren Patel <patelhn@telkom > try finding out what packages depend on libx.so, remove those packages, > upgrade the package containing the shared libs, install the package > contain the one isolated lib, and then install the packages you removed > that depended on libx.so > > On Thu, 2007-06-21 at 12:54 -0500, Xavier Toth wrote: > > I've verified that the shared library has it executable mode bits set. > > > > On 6/21/07, Jeff Johnson <n3npq.jbj@xxxxxxxxx> wrote: > > > > > > On Jun 21, 2007, at 1:13 PM, Xavier Toth wrote: > > > > > > > I previously had a package in which rolled up a number of shared > > > > libraries. Now I've placed one of the shared libraries in its own > > > > package. So now the shared library package no longer provides I'll > > > > call it libx.so and the new package does. Other installed packages > > > > depend on the libx.so shared library. When I try and update the shared > > > > library package it fails because of the dependency of other packages > > > > on the shared library that it previously provided. Also if I try and > > > > install the new package it fails because of the conflict with the > > > > shared library package over the providing of libx.so. What is the > > > > correct way to handle such a situation? I'd prefer not to resort to > > > > --force or --replacefiles. > > > > > > > > > > You likely have forgotten the executable bit on the refactored libx.so > > > library. Otherwise, you need a DT_SONAME in the library. > > > > > > rpm tries very hard to never automagically extract dependency info for > > > non-executables. > > > > > > hth > > > > > > 73 de Jeff > > > > > > _______________________________________________ > > > 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 > -- > > Hiren Patel | Ops Specialist | ISS Infrastructure | Telkom > E-Mail: patelhn@xxxxxxxxxxxx Office: +27 12 680 3460 | Fax: +27 12 680 > 3299 | Cell: +27 73 456 7980 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > This e-mail and its contents are subject to the Telkom SA Limited > e-mail legal notice available at > http://www.telkom.co.za/TelkomEMailLegalNotice.PDF > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > 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 _______________________________________________ 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
