Re: refactored packages cause conflict/dependency issue

[Jeff Johnson <n3npq jbj gmail com>]

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