RPM's multi-architecture file ownership problem
An increasing number of Red Hat/Fedora machines are dual architecture: they run both 64-bit and 32-bit x86 programs, and thus need to have shared libraries and RPMs and so on for both of them. This can expose some interesting issues when installing and upgrading RPMs; one of them is the dual architecture file ownership problem.
There are a lot of RPMs that install both architecture-dependent files
like binaries and shared libraries and architecture-independent files
like header files and manpages. The architecture dependent files
already go into different places, so you can
easily install both the x86 and x86_64 versions at the same
time, but the same is not true of architecture-independent files;
there is only one
The RPM people decided that the easiest solution to this problem was to allow more than one RPM to supply the same file, provided that all versions of the file were exactly the same. That way, if libfoo.x86 and libfoo.x86_64 provide exactly the same manpages, they can coexist, and anyways there's no reason for the manpages to be different just because of the architecture you built the RPM for; such differences are effectively a bug.
However, this has a side effect: you usually have to upgrade the RPMs for both architectures at the same time, because there is no guarantee that libfoo-1.1.x86 will have the same manpages as libfoo-1.2.x86_64. If you can't do this (perhaps all the necessary RPMs aren't in the updates repository yet), you get weird errors about how files from libfoo-1.2 conflict with files from libfoo-1.1 (unhelpfully, yum doesn't tell you the architectures of the RPMs involved).
Sometimes you can deal with this by removing the RPM for the unavailable library, but sometimes you really do need the x86 version of libfoo and you're stuck until libfoo-1.2.x86 gets built and pushed out.
In fact, if you stick to well-run repositories, file conflict
errors on a dual architecture machine are almost always the sign of
an architecture clash. Well run repositories just don't normally
allow RPMs with clashing files, so the only way to get a file clash is
yum is somehow pulling in an RPM from the wrong architecture.
(Unfortunately, hunting down where and why can be challenging.)