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
