Caution! Bad SONAME Provides

[Ruben Kerkhof]

On 22-jun-2007, at 17:02, 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.

Funny, a user of one of my packages, csync2, reported upstream that  
he had a problem with my package on F-7.
He got "unresolved symbol" errors. It turns out that somehow csync2  
got linked to sqlite3, while it has a BuildRequires on sqlite2-devel

Until reading this thread, I had no idea how this happened, so I  
installed F-7 on a new box, and did a yum install csync2.
Yum wanted to pull in dbmail as a dependency, but that's strange,  
since csync2 shouldn't use dbmail.

Turns out dbmail provides libsqlite.so.0 (it's in /usr/lib/dbmail/ 
libsqlite.so.0), which is a sqlite3 library.

I'm glad I've found this, but it would be great if we could somehow  
prevent things like this happening.

Ruben