Solving RPM installation conflicts in CentOS 5 and CentOS 6

Lately we’ve had many reports of the RPM packages for CentOS 5 (mostly) and CentOS 6 having issues when installing different combinations of our products, particularly with Percona Toolkit for MySQL. Examples of bugs related to these issues are lp:1031427 and lp:1051874.

These problems arise when trying to install a package from the distribution that is linked against the version of shipped by the distribution ( for CentOS 5/ for CentOS 6) and a version of Percona Server that depends on another version of, usually more recent. Bug lp:1031427 is an example of this, and shows how the packages would conflict when trying to install

For example, when installing php-mysql alongside PS 5.5 in CentOS 6:

# yum -q install Percona-Server-server-55 php-mysql

Percona-Server-server-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 15 M
php-mysql x86_64 5.3.3-14.el6_3 updates 79 k
Installing for dependencies:
Percona-Server-client-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 7.0 M
Percona-Server-shared-51 x86_64 5.1.67-rel14.3.506.rhel6 percona 2.8 M
Percona-Server-shared-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 787 k

Transaction Summary
Install 5 Package(s)

Is this ok [y/N]: y

Transaction Check Error:
file /usr/lib64/ conflicts between attempted installs of Percona-Server-shared-51-5.1.67-rel14.3.506.rhel6.x86_64 and Percona-Server-shared-55-5.5.29-rel29.4.401.rhel6.x86_64
file /usr/lib64/ conflicts between attempted installs of Percona-Server-shared-51-5.1.67-rel14.3.506.rhel6.x86_64 and Percona-Server-shared-55-5.5.29-rel29.4.401.rhel6.x86_64

The traditional solution for this situation was to provide a special package, Percona-Server-shared-compat (modeled after upstream’s MySQL-shared-compat) which would contain ALL versions of* together and wouldn’t conflict. Probably some of you are familiar with this approach.

# yum -q install Percona-Server-server-55 Percona-Server-shared-compat php-mysql

Percona-Server-server-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 15 M
Percona-Server-shared-compat x86_64 5.5.29-rel29.4.401.rhel6 percona 3.4 M
php-mysql x86_64 5.3.3-14.el6_3 updates 79 k
Installing for dependencies:
Percona-Server-client-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 7.0 M
Percona-Server-shared-55 x86_64 5.5.29-rel29.4.401.rhel6 percona 787 k

Transaction Summary
Install 5 Package(s)

Notice how PS-shared-compat installs along the -shared package, providing the older required by php-mysql.

However, this has proved non-intuitive and problematic, since the shared-compat package wouldn’t get selected unless explicitely installed — and many of our users would rather have it “just work” without requiring additional knowledge of what the particular workaround was, etc..

We’re now trying a solution in which our -shared packages won’t conflict anymore at, so we are able to install them side-by-side, modelled after the mysql-libs packages provided by CentOS/Redhat. So even if the user wants to install PS 5.5 alongside packages that depend on 5.1/5.0, the -shared packages will work together. For example installing 5.5 and postfix in CentOS:

# yum -q install Percona-Server-server-55 postfix

Percona-Server-server-55 x86_64 5.5.29-rel29.4.402.rhel5 percona-testing 19 M
postfix x86_64 2:2.3.3-6.el5 base 3.8 M
Installing for dependencies:
Percona-SQL-shared-50 x86_64 5.0.92-b23.89.rhel5 percona-testing 1.8 M
Percona-Server-client-55 x86_64 5.5.29-rel29.4.402.rhel5 percona-testing 9.1 M
Percona-Server-shared-55 x86_64 5.5.29-rel29.4.402.rhel5 percona-testing 993 k


… and this will install without problems.

Additionally, this has the advantage of allowing an upgrade from 5.1 to 5.5 without uninstalling any software that depended on the old version.

# rpm -qa | grep ^Percona

In this case only Percona-Server-client-51 and Percona-Server-server-51 need be removed, allowing any package that depends on Percona-Server-shared-51 (providing to remain installed. After the server and client packages are uninstalled, you can install PS 5.5 without conflict.

The current package candidates for versions 5.0.92 (which required an update), 5.1.67-14.3 and 5.5.29-29.4 can be tested from the percona-testing repository. We encourage you to try these out and send us your feedback and/or file any bugs you find.

Installation instructions for Percona Testing repositories.

We’re aiming to include these fixes in our next releases of Percona Toolkit 5.1 and Percona Toolkit 5.5. Percona Toolkit users in particular will enjoy this update since it’ll mean no more trouble when installing it from repository!

Share this post

Comments (7)

  • marcos.albe

    You rock my repos Ignacio! Thanks so much! 🙂

    February 21, 2013 at 12:16 pm
  • guly

    this is not limited to centos, i had some issues also on debian/ubuntu (don’t know if latest packages works better for dependencies, sorry). while you’re fixing rpm spec file, could you please have a look also to deb ? thanks 🙂

    February 21, 2013 at 12:38 pm
  • Ignacio Nin

    Hey guly!

    Our debian packages already use these approach — based in the original distribution files for 5.1 in which we based our percona packages.

    Of course, this doesn’t mean they’re free of issues 🙂 Have you experienced any when installing our software? If so, please let me know of the particular problem and I’ll take a look into it.


    February 21, 2013 at 1:07 pm
  • hailong guo

    nice to meet you!
    now,i meet a trouble and need your help!
    i setup percona cluster in vm, if in file /etc/my.cnf,i add wsrep_cluster_address=gcomm:// to fill it ,the mysql server will not running

    [root@mysql1 ~]# vi /etc/my.cnf

    the wrong infomaton :

    130221 17:59:00 mysqld_safe WSREP: Running position recovery with –log_error=/tmp/tmp.cuCEbd7883
    130221 17:59:05 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
    130221 17:59:05 [Note] WSREP: wsrep_start_position var submitted: ‘00000000-0000-0000-0000-000000000000:-1’
    130221 17:59:05 [Note] WSREP: Read nil XID from storage engines, skipping position init
    130221 17:59:05 [Note] WSREP: wsrep_load(): loading provider library ‘/usr/lib/’
    130221 17:59:05 [Note] WSREP: wsrep_load(): Galera 2.3(r143) by Codership Oy loaded succesfully.
    130221 17:59:05 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
    130221 17:59:05 [Note] WSREP: Reusing existing ‘/var/lib/mysql//galera.cache’.
    130221 17:59:05 [Note] WSREP: Passing config to GCS: base_host =; base_port = 4567; cert.log_conflicts = no; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 2147483647; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; replicator.causal_read_timeout = PT30S; replicator.commit_order = 3
    130221 17:59:06 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
    130221 17:59:06 [Note] WSREP: wsrep_sst_grab()
    130221 17:59:06 [Note] WSREP: Start replication
    130221 17:59:06 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
    130221 17:59:06 [Note] WSREP: protonet asio version 0
    130221 17:59:06 [Note] WSREP: backend: asio
    terminate called after throwing an instance of ‘gu::NotFound’
    01:59:06 UTC – mysqld got signal 6 ;
    This could be because you hit a bug. It is also possible that this binary
    or one of the libraries it was linked against is corrupt, improperly built,
    or misconfigured. This error can also be caused by malfunctioning hardware.
    We will try our best to scrape up some info that will hopefully help
    diagnose the problem, but since we have already crashed,
    something is definitely wrong and this may fail.
    Please help us make Percona Server better by reporting any
    bugs at

    It is possible that mysqld could use up to
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 329809 K bytes of memory
    Hope that’s ok; if not, decrease some variables in the equation.

    Thread pointer: 0x0
    Attempting backtrace. You can use the following information to find out
    where mysqld died. If you see no messages after this, something went
    terribly wrong…
    stack_bottom = 0 thread_stack 0x30000
    You may download the Percona Server operations manual by visiting You may find information
    in the manual which will help you identify the cause of the crash.
    130221 17:59:06 mysqld_safe mysqld from pid file /var/lib/mysql/ ended

    can you help me to solve this program?

    February 21, 2013 at 9:09 pm
  • Daniël van Eeden

    And with the mysql vs. /usr/bin/mysql changes in the Oracle packages it will even get harder to get the correct dependencies:

    February 22, 2013 at 3:22 am
  • Michal Hrusecky

    What we (openSUSE) do is that ‘*.so’ file is only in devel package and libraries are in ‘various packages with shared libraries each one providing only ‘*.so.*’ files. Unfortunatelly that doesn’t solve problems if you have multiple libraries with same version like having distribution compiling against Oracles MySQL (and wanting to play it safe) and wanting to use MariaDB. I ended up with renaming the library on non-default databases, just to be sure…

    February 28, 2013 at 10:08 am
  • Tarun

    What would you recommend in the following scenario?

    I have the following installed on a CentOS 5.5. The percona-server-shared package is installed

    => Percona-Server-server-55-5.5.39-rel36.0.el5
    => Percona-Server-shared-55-5.5.39-rel36.0.el5
    => Percona-Server-client-55-5.5.39-rel36.0.el5
    => percona-toolkit-2.1.4-1

    I am unable to use percona toolkit utilities because of its dependencies and its conflicts (see example below)

    04-15T14:29:36 Cannot connect to MySQL because the Perl DBD::mysql module is not installed or not found. Run ‘perl -MDBD::mysql’ to see the directories that Perl searches for DBD::mysql. If DBD::mysql is not installed, try:
    Debian/Ubuntu apt-get install libdbd-mysql-perl
    RHEL/CentOS yum install perl-DBD-MySQL
    OpenSolaris pgk install pkg:/SUNWapu13dbd-mysql

    I am unable to install percona xtrabackup because of dependencies and conflicts again

    sudo yum install percona-xtrabackup
    Reading version lock configuration
    Setting up Install Process
    Resolving Dependencies
    –> Running transaction check
    —> Package percona-xtrabackup.x86_64 0:2.2.10-1.el5 set to be updated
    –> Processing Dependency: perl(DBD::mysql) for package: percona-xtrabackup
    –> Running transaction check
    —> Package perl-DBD-MySQL.x86_64 0:4.013-3.el5 set to be updated
    –> Processing Dependency: for package: perl-DBD-MySQL
    –> Processing Dependency: for package: perl-DBD-MySQL
    –> Running transaction check
    —> Package mysql-libs.x86_64 0:5.1.73-4.el5 set to be updated
    –> Finished Dependency Resolution

    Dependencies Resolved

    Package Arch Version Repository Size
    percona-xtrabackup x86_64 2.2.10-1.el5 6.2 M
    Installing for dependencies:
    mysql-libs x86_64 5.1.73-4.el5 1.7 M
    perl-DBD-MySQL x86_64 4.013-3.el5 147 k

    Transaction Summary
    Install 3 Package(s)
    Upgrade 0 Package(s)

    Total size: 8.1 M
    Is this ok [y/N]: y
    Downloading Packages:
    Running rpm_check_debug
    Running Transaction Test
    Finished Transaction Test

    Transaction Check Error:
    file /etc/my.cnf from install of mysql-libs-5.1.73-4.el5.x86_64 conflicts with file from package Percona-Server-server-55-5.5.39-rel36.0.el5.x86_64

    April 15, 2015 at 6:07 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.