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 redhat com
https://www.redhat.com/mailman/listinfo/rpm-list