As discussed on devel list, rpm's mechanism for extracting library requirements suffers from a problem. It extracts the SONAME of a library but the SONAME is not sufficient to guarantee that a program will run with the library as a library is free to add API and ABI and keep the same SONAME (the SONAME specifies a base version of the ABI but there may be additions to that ABI that a program compiled against a newer program would require.)

The case where this breaks things is if the user has libfoo-1.0 installed. The package maintainer updates libfoo to libfoo-1.1, which has the same SONAME due to maintaining backwards compatibility but it has added API and ABI. Another package, bar uses some of that new API and is compiled against libfoo-1.1. The user either installs (yum install bar) or upgrades an existing bar (yum update bar). This installs the version of bar compiled against the new libfoo on the user's system but does not upgrade libfoo (because the dependency is on the SONAME, not on the actual API/ABI or the package NEVR). When the user tries to run bar, it fails because it tries to use a feature of libfoo-1.1 that isn't present in the libfoo-1.0 version on his system.

There's two things that could be changed here:

1. We could request that rpmbuild be changed to specify more version information. Simo and others suggested that the dep generated include the full NEVR for the library

2. We can update: https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires to list this as one of the cases where an Explicit Requires is necessary.

Here's a proposed change:

"""
Explicit Requires are Requires added manually by the packager in the spec file. ~~Packages must not contain explicit Requires on libraries except when absolutely necessary. When explicit library Requires are necessary, there should be a spec file comment justifying it. Explicit library dependencies should typically be arch-specific (unless the packages involved are noarch).~~ We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. Modern package management tools are capable of resolving such dependencies to determine the required packages in many cases. ~~Explicit dependencies on specific package names may aid the inexperienced user, who attempts at installing RPM packages manually, however,~~ However, present versions of rpmbuild only add deps on library SONAMES, not the library's full version. This can be a problem if a library has added features over the course of time without backwards incompatibilities that would cause SONAMES to be changed. This can lead to a case where the user has an old version of a library installed, the new version of the library with new ABI is built in Fedora and an application using that ABI is built. If the user just attempts to install or update that one application without explicitly updating the library, the application will install fine (because the SONAME dependency is satisfied) but will fail when run because the library installed on the system is missing features it needs.

Although you do need to add explicit library dependencies to keep this from occurring, there are drawbacks to manually specifying this in all your packages. History has shown that such dependencies add confusion when library/files are moved from one package to another, when packages get renamed, when one out of multiple alternative packages would suffice, and when versioned explicit dependencies become out-of-date and inaccurate. Additionally, in some cases, old explicit dependencies on package names require unnecessary updates/rebuilds. For example, Fedora packages are only required to retain historical provides for two full release cycles.

Because of this and because we hope to have this fixed in rpmbuild, this is something to be aware of but it's not required that you explicitly specify the libraries you require with their version information.

When explicit library Requires are necessary, explicit library dependencies should typically be arch-specific (unless the packages involved are noarch) and there should be a spec file comment justifying it:

{{{
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar%{?_isa} >= 0:1.2.3-7
}}}

Packagers should revisit an explicit dependency as appropriate to avoid it becoming inaccurate and superfluous. For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.
"""

(Full devel list thread is here: http://lists.fedoraproject.org/pipermail/devel/2011-August/155482.html One of the posts that most succinctly highights what's broken is here: http://lists.fedoraproject.org/pipermail/devel/2011-August/155549.html )