This message is based on one I sent to Troy earlier and may affect those 
using x86_64 with sl5 who either upgrade to sl53 or apply the recent 
security errata for dbus.

With the new sl5 dbus-1.1.2 the x86_64 and i386 versions clash in the 
contents of a config file so anaconda (say) won't allow both to be 
installed (which is fine since now you just want dbus-libs.i386).  However 
a yum upgrade from a machine which has dbus.i386 and dbus.x86_64 installed 
WILL manage to install both version but rpm -V will show that neither is 
entirely happy about their files.

After doing much testing (which I amd not going to bore you with), I found 
the following TUV buzilla report:

    https://bugzilla.redhat.com/show_bug.cgi?id=471359

So the conflicts are just in the path to some help files and timestamps in 
the docs and they are leaving fixing this properly until EL 5.4

ie no actual harm will come from having the conflict, except that the 
packages installed end up not being the same as you would get from a clean 
install and possibly there might be some problems with conflicts on future 
updates.

Anyone using x86_64 who cares about this should probably do a rpm -e 
dbus.i386 (after dbus-libs.i386 is present or it won't work)

    yum update dbus
    rpm -e dbus.i386 dbus-devel.i386

that will still result in the /etc/dbus-1/system.conf having the wrong 
contents and some help files get removed, so perhaps the following is 
better though being forced to use nodeps is rather less pleasing:

    rpm -e --nodeps dbus.i386 dbus-devel.i386
    yum install dbus.x86_64 dbus-libs.i386 dbus-glib.i386

which is ugly but seems to work as probably would:

    rpm -e dbus.i386 dbus-devel.i386
    rpm -e --nodeps --justdb dbus.x86_64
    yum install dbus.x86_64

which may also work after the dbus update since it will force the 
dbus.x86_64 package to be re-installed...

I've added the following to my sl5 update wrapper (which eventually calls 
yum to do the actual updates) - this is probably overkill but you get the 
idea:

...
if [ "$RPMA" = "x86_64" ]; then
     DBUS32=$(rpm -q --queryformat '%{name}-%{version}-%{release}.%{arch}\n' dbus.i386 2>/dev/null)
     if [ "$DBUS32" != "" ]; then
 	echo "Need to remove $DBUS32 since clashes on $RPMA"
 	rpm -e --nodeps dbus.i386 dbus-devel.i386
     fi
     DBUSLIBS32=$(rpm -q --queryformat '%{name}-%{version}-%{release}.%{arch}\n' dbus-libs.i386 2>/dev/null | grep -v 'is not installed')
     if [ "$DBUSLIBS32" = "" ]; then
 	echo "ensuring dbus-libs.i386 is present"
 	yum -d 0 -y install dbus.x86_64 dbus-libs.i386 dbus-glib.i386 2>/dev/null
     fi
fi

None of this is SL's fault, it is just how the TUV chose to change the 
dbus packaging which causes the uglyness.

  -- Jon