3

i'm facing the following error:

Transaction Check Error:
package apr-1.3.12-1.jason.1.x86_64 (which is newer than apr-1.2.7-11.el5_6.5.cloudlinux.2.i386) is already installed

This is on cloudlinux. apr-1.3.12-1.jason.1.x86_64 is installed from a 3rd Party repo and now any package update seems to require an older version of apr or doesn't even notice that a newer version is installed.

What's the smartest way to solve this solution? Unfortunately i don't exactly know which package needs this dependecy (what's the way to find that out?)

Lokari
  • 31
  • 1
  • 2
  • Which architecture are you running: 32 or 64 bits? Which package are you installing? Show the repo list `yum repolist`? – quanta Oct 28 '11 at 06:04

2 Answers2

1

If you want to keep using the 3rd party repo and yet you are required to use an earlier version, you could do a yum downgrade apr.

You could however remove apr (yum erase apr) and then re-install standard repo packages for the ones removed.

[edit 1]:

It looks like you have a version mismatch between your 32bit version and 64bit version of apr, you can try running yum update apr.i386 apr.x86_64. You'll need to do this with your 3rd party repo enabled.

Andrew Case
  • 3,489
  • 3
  • 23
  • 39
  • I think the update to the system should also work without having an older version - my preferred way would be to ignore the dependency if possible. – Lokari Nov 10 '11 at 06:50
  • See updated answer. – Andrew Case Nov 10 '11 at 18:30
  • I had this conflict on one of VMs. The problem was both x32 and x64 `apr` was installed. In my case x64 had dependencies to httpd, php etc... So removing unused x32 was correct choice: `yum erase apr.i386`. – Nux Jan 29 '21 at 13:16
1

Both @ACase suggestions of yum erase apr and yum downgrade apr are good, however if you wanted to do a little more investigation and see what is the offending app you can do the following;

You can check which installed packages require the blocking "apr-1.3.12-1.jason.1.x86_64" package like so;

# rpm -q --whatrequires apr
**apr-devel-1.2.7-11.el5_6.5**  <--(this or something else in the list)
...

apr is the "apache portable runtime", and was presumably installed as a library by some other httpd related software package transaction.

And then you can see the dependencies of that offending package by using the following command;

# rpm -v -q --requires apr-devel
/sbin/ldconfig  
libapr-1.so.0()(64bit)  
libc.so.6()(64bit)  
....

To see what dependencies are required by the new package that you are trying to install from repository you can use;

# yum deplist apr
Finding dependencies: 
package: apr.i386 1.2.7-11.el5_6.5
  dependency: libc.so.6(GLIBC_2.1.3)
   provider: glibc.i686 2.5-65
   provider: glibc.i686 2.5-65.el5_7.
...

In more general terms, the problem is that the old and the new packages conflict and you will have to solve the problem by deciding which set of packages you are going keep and which to remove.

I personally would prefer to keep the use the distro version of the apr package, as it is used by a bunch of apache based softwares.

To see crazy verbose output of yum trying to find the deps for you, add the -v flag;

# yum -v deplist apr
...
pkgsack time: 3.261
rpmdb time: 0.000
Finding dependencies: 
Searching pkgSack for dep: /sbin/ldconfig
Potential match for /sbin/ldconfig from glibc-2.5-65.i686
Potential match for /sbin/ldconfig from glibc-2.5-65.x86_64
...
Tom
  • 11,176
  • 5
  • 41
  • 63