Bug 171143

Description of problem:

On installations where may be installed packages with the same name but for
different architectures, like for x86_64, the following may occur.

Let say that we have on a system 'package.archA' and 'package.archB' and for
whatever reasons (availabilty or a partial failure) yum attempts to update
only a 'package.archA'.

One possible outcome, when both packages have some files in common, is
that the whole transaction fails with complaints about file conflicts
which are somewhat "mysterious" until one start to look very close at versions
and architectures (which seems too confusing and difficult for many users).

The other, actually worse, situation is that an update of one of these
packages gets through.  Subsequently it will be not noticed, I think that
on an rpmlib level, that the other package from the pair needs an update too
even if it will become availalble and/or possible.

An example of the later in practice happened recently with updates to FC3.
If both libwpd-0.7.2-1.i386 and libwpd-0.7.2-1.x86_64 were installed, with
i386 variant used by openoffice - I think, then an update to libwpd-0.8.2-1.fc3
was getting through for i386 but failing for x86_64 due to a broken
dependency in a version of abiword which was present at that time.  After
that everything was up-to-date according to all tools when clearly it was not.

Due to all of that it seems that yum is missing a "multilib check" where
a transaction for a set of packages like above succeeds only if this is
true for all set members.  If such check can be moved down to rpmlib that
would be possibly even better.