I ran into a troublesome error the other day that I thought was worthwhile writing about. When updating an ESX vmware server with YUM (package manager), I encountered a transaction failure message. The message indicates that there was a conflict in the order of the updates. In this case a subversion package that is 64bit is conflicting with a similar 32bit package:

Transaction Check Error:
file /usr/share/emacs/site-lisp/psvn.el from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/de/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/es/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/fr/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/it/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/ja/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/ko/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/nb/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/pl/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/pt_BR/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/sv/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/zh_CN/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/locale/zh_TW/LC_MESSAGES/subversion.mo from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/man/man1/svn.1.gz from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/man/man1/svnadmin.1.gz from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/man/man1/svnlook.1.gz from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/man/man5/svnserve.conf.5.gz from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/man/man8/svnserve.8.gz from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
file /usr/share/xemacs/site-packages/lisp/psvn.el from install of subversion-1.6.6-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386

The solution is straightforward. Install a yum plugin that allows the prioritization of which repositories are checked for updates and updated first. In this particular case, I only modified the main base repo. The new lines that were added assign each repo a priority from 1 to 99:

  • priority =1
  • priority = 2


vi /etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
priority=2

Next, install yum priorities
yum install yum-priorities
And finally run yum update again. This time there were no transaction failures!