Description of problem: My test installation have at this moment only "x86_64" and "noarch" packages. Instead of just updating what is there with the latest series of updates yum suddenly decides to do the following: Installing: dbus-glib x86_64 0.70-3 development 154 k replacing dbus-glib.x86_64 0.62-1.1 dbus-glib i386 0.70-3 development 153 k replacing dbus-glib.x86_64 0.62-1.1 dbus-glib-devel x86_64 0.70-3 development 9.9 k replacing dbus-devel.x86_64 0.62-1.1 dbus-glib-devel i386 0.70-3 development 9.9 k replacing dbus-devel.x86_64 0.62-1.1 dbus-python x86_64 0.70-4 development 187 k replacing dbus-python.x86_64 0.62-1.1 In particular i386 packages are "replacing" x86_64 ones and which were already "replaced" by something else. As a side effect this pulls in, via "Installing for dependencies", the following audit-libs i386 1.2.5-3 development 39 k dbus i386 0.90-6 development 639 k expat i386 1.95.8-8.2.1 development 77 k glib2 i386 2.12.0-1.1 development 660 k glibc i686 2.4.90-13 development 5.0 M libcap i386 1.10-25 development 22 k libselinux i386 1.30.19-3 development 89 k libsepol i386 1.12.19-1.1 development 140 k All in all ten "extra" packages not really used by anything. Any weighty reasons why? Well, dependencies clearly need to be resolved once it was decided that some "i386" packages are "in". yum does not have any problems afterwards with a removal of that whole bunch. Version-Release number of selected component (if applicable): yum-2.9.3-1 How reproducible: no idea; from some past observations probably not that easily
The 'replacing' comment is how an obsolete is phrased in the output. So dbus-glib.x86_64 is being replaced by dbus-glib. obsoletes aren't arch-specific.
yum is doing the right thing here, it's a bug in the dbus-glib packaging -- and I just saw jesse building fixed packages