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
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
