Hi James,
why would I need the common package? It is not needed at all.

See below:

# rpm -q bz727606-pkg
bz727606-pkg-0.8.6-4.el6.noarch
# rpm -Uvh bz727606-pkg.new.rpm
Preparing...                ########################################### [100%]
   1:bz727606-pkg           ########################################### [100%]
# rpm -q bz727606-pkg
bz727606-pkg-0.9.0-4.el6.x86_64
# 
# rpm -Uvh --oldpackage bz727606-pkg.old.rpm
Preparing...                ########################################### [100%]
   1:bz727606-pkg           ########################################### [100%]
# rpm -q bz727606-pkg
bz727606-pkg-0.8.6-4.el6.noarch
# yum -y localupdate bz727606-pkg.new.rpm
Loaded plugins: security
Setting up Local Package Process
Examining bz727606-pkg.new.rpm: bz727606-pkg-0.9.0-4.el6.x86_64
Marking bz727606-pkg.new.rpm as an update to bz727606-pkg-0.8.6-4.el6.noarch
Nothing to do

I'm confused ... what is the obsoletes line there for then?

AIUI this bug was about changing arch and thus. obsoleting the old version of yourself ... but that didn't work without the new pkg. being in a repo.

(In reply to comment #16)
> I'm confused ... what is the obsoletes line there for then?
> 
> AIUI this bug was about changing arch and thus. obsoleting the old version
> of yourself ... but that didn't work without the new pkg. being in a repo.

I believe now I know the source of the confusion. Similar issue has been already reported in bug 709225. The situation was:

pkgA-1.0-1.noarch should be updated to pkgA-2.0-1.x86_64

and yum didn't update the package. It was necessary for pkgA-2.0-1 obsoleted the previous version (see 709225#c5).

Situation in this bug is very similar. We have

virt-manager-0.8.6-4.el6.noarch should be updated to virt-manager-0.9.0-6.el6.x86_64
The thing is that there exists also virt-manager-common package (https://apps.fedoraproject.org/packages/virt-manager-common) and to pull in the same version of from various reasons virt-manager-0.9.0-6.el6 contains in SPEC

%define with_tui   0
...
%if %{with_tui} == 0
Obsoletes: virt-manager-common <= %{verrel}
Conflicts: virt-manager-common > %{verrel}
%else
Requires: virt-manager-common = %{verrel}
%endif

This is the conflict I have placed to my test packages (and the conflict that confused you). But what is actually needed is
Obsoletes: virt-manager < %{verrel} 
what ensures that the package is properly updated from noarch package.

So the problem here is actually the same as in the bug 709225. To fix it the virt-manager SPEC should be updated with proper Obsoletes and this bug can be closed as not a bug. 

James, what do you think?

 Yeh, I think we just miscommunicated for a bit there :).

 After talking on IRC a bit we both agreed this can just be closed as a dup. of 709225, also Karl asked:

<ksrot> why rpm works and yum not? I mean, if we don't have really good answer for that, we may get into this situation again and again. unfortunately there is not such explanation in bug 709225

<james> The short answer is that yum's depsolver is different to rpm's depchecker … and yum's doesn't treat cross arch upgrades in the same way.

...and asked to preserve that here, so people can find it.

*** This bug has been marked as a duplicate of bug 709225 ***

virt-manager bug filed as bug 872611