Caution! Bad SONAME Provides

[Adam Jackson]

On Fri, 2007-06-22 at 17:02 +0200, Michael Schwendt wrote:
> Broken dependencies are one thing, broken "Provides" another.
> 
> The distribution includes an increasing number of packages, which don't
> filter their SONAME Provides when they include shared libraries in private
> paths.
> 
> This can have devastating effects in conjunction with yum's "shortest
> package name wins" during depsolving. For example:
> 
>   libfoo  provides  libfoo.so.1   for %{_libdir}/libfoo.so.1
>   bar     provides  libfoo.so.1   for %{_libdir}/bar/plugins/libfoo.so.1.0.0
> 
> Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And even if
> "bar" extended the ld.so configuration, it would conflict with libfoo in
> what it provides.
> 
> I've reported a few such cases. All the others look like packages provide
> sonames for plugin libraries without actually conflicting with any library
> package in the Fedora Collection. Still it's dangerous if multiple packages
> provide "libfoo.so" (versioned or not), but neither one puts the library
> into run-time linker's search path. Sooner or later such dependencies
> might explode at run-time.
> 
> Reviewers ought to examine "Provides" carefully and require packagers to
> filter the Provides if necessary.

How should I filter these, short of AutoReqProv: 0 ?

- ajax