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
