Dependency Challenge with CentOS

Question

Given the following output, suggestions on what to try first? This is on a CentOS 5.3 box (upgraded from 5.2 via yum) running as a little dev server. I'm generally comfortable with *nix, but dependency chasing leaves me a bit perplexed at times. So this time I'm seeking help before I run amuck.

Output from today's "yum update":

Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package perl-Net-SSLeay.i386 0:1.35-1.el5.rf set to be updated
---> Package perl-IO-Socket-SSL.noarch 0:1.26-1.el5.rf set to be updated
---> Package perl-Net-DNS.i386 0:0.65-1.el5.rf set to be updated
---> Package perl-Package-Constants.noarch 0:0.02-1.el5.rf set to be updated
---> Package perl-IO-Compress.noarch 0:2.020-1.el5.rf set to be updated
--> Processing Dependency: perl(Compress::Raw::Bzip2) >= 2.020 for package: perl-IO-Compress
--> Processing Dependency: perl(Compress::Raw::Zlib) >= 2.020 for package: perl-IO-Compress
--> Running transaction check
---> Package perl-Compress-Raw-Bzip2.i386 0:2.015-1.el5.rf set to be updated
---> Package perl-IO-Compress.noarch 0:2.020-1.el5.rf set to be updated
--> Processing Dependency: perl(Compress::Raw::Zlib) >= 2.020 for package: perl-IO-Compress
--> Finished Dependency Resolution
perl-IO-Compress-2.020-1.el5.rf.noarch from rpmforge has depsolving problems
  --> Missing Dependency: perl(Compress::Raw::Zlib) >= 2.020 is needed by package perl-IO-Compress-2.020-1.el5.rf.noarch (rpmforge)
Error: Missing Dependency: perl(Compress::Raw::Zlib) >= 2.020 is needed by package perl-IO-Compress-2.020-1.el5.rf.noarch (rpmforge)

perl(Compress::Raw::Zlib) is a package name?!? If so, I get this on an update attempt:

Package perl-Compress-Raw-Zlib-2.015-1.el5.rf.i386 already installed and latest version

Wrong version, yet says it is the latest...

Just in case this is helpful:

$ uname -a
Linux EFhermesDev 2.6.18-128.1.16.el5.centos.plus #1 SMP Wed Jul 1 13:06:47 EDT 2009 i686 i686 i386 GNU/Linux

Solution 1

You are seeing an rpmforge dependency problem, not a CentOS dependency problem.

rpmforge perl modules are mass rebuilt at the moment. See http://lists.rpmforge.net/pipermail/users/2009-July/002508.html ff.

Solution 2

Note that from CentOS-5.3 onwards you can try:

   yum update --skip-broken

...this will likely work even better in 5.4.

Solution 3

You can get version 2.020 here (readme). It was released June 3, 2009.

Background:

The dependency is calling for a newer version than your repository thinks is the newest version:

Error: Missing Dependency: perl(Compress::Raw::Zlib) >= 2.020 is needed by package perl-IO-Compress-2.020-1.el5.rf.noarch (rpmforge)

You have an older version installed than the dependency calls for:

Package perl-Compress-Raw-Zlib-2.015-1.el5.rf.i386 already installed and latest version

As it says, you need to install:

perl(Compress::Raw::Zlib) >= 2.020

in order to resolve this dependency.

Solution 4

That's because the repository you are using is out of sync with itself.

Browse this site.

As of this post, the perl-IO-Compress.noarch package was updated to 2.020 and it depends on a 2.020 version of perl-Compress-Raw-Zlib.

However, the perl-Compress-Raw-Zlib is still at 2.015. You can wait till they catch up or you can ignore perl-IO-Compress.noarch in yum till then.

Try adding:

exclude=perl-IO-Compress*

to /etc/yum.conf. (Haven't tested this, you may have to add other excludes, Try this from the command line and see what happens before adding to yum.conf)

You should be using the EPEL repo for things like this as far as possible. EPEL is a Fedora sub project and has higher standards.

Try to remove any rpmforge packages (and the yum repository) and use EPEL only.

View more solutions

Comments

[Chris_K]

right. I have 2.015 and it wants 2.020. yum update for that gives the output I listed above ("already installed and latest version"). Thus my question here :-)

[eleven81]

edited to provide a link to the depended-upon version.. =)

[Chris_K]

Ah, that's good to know. So maybe I just wait a day or two then?

[Chris_K]

Did you have any luck?

[Chris_K]

Agreed! I did make a note, however, to give EPEL a closer look when I build my next CentOS server.

[Admin]

Not with that, but yum erase perl-Compress-Raw-Zlib yum -y update worked (ish) The erase took other things with it that I had to reinstall, (your list will probably not match mine, but here is mine for comparison.) yum -y install munin-node perl-libwww-perl spamassassin also I had to: srvadmin-services.sh start after the yum -y update (Thanks serverfault.com/users/1936/chrisk for the confidence - I didn't really want to take a chance with my production server.) Sadly omreport (Dell OpenManage) has stopped working, but I'll look into that and report back.

[Admin]

omreport now spits out /etc/delloma.d/oma/bin/omcliproxy: error while loading shared libraries: libdsupt32.so.1: cannot open shared object file: No such file or directory so I've fixed the yum update issue and now can't see if my server is over heating, (or if the data centre is too hot)

[Admin]

To test I did: <pre>ln -s /opt/dell/srvadmin/oma/bin/libdsupt32.so.1.100.276 /usr/lib/libdsupt32.so.1 ln -s /opt/dell/srvadmin/oma/bin/libomacs32.so.1 /usr/lib/libomacs32.so.1 ln -s /opt/dell/srvadmin/oma/bin/libomclpr32.so.3 /usr/lib/libomclpr32.so.3 ln -s /opt/dell/srvadmin/oma/bin/libomcldb32.so.3.70.276 /usr/lib/libomcldb32.so.3 ln -s /opt/dell/srvadmin/oma/bin/libomclpr32.so.3 /usr/lib/libomclpr32.so.3 ln -s /opt/dell/srvadmin/oma/bin/libomadb32.so.3 /usr/lib/libomadb32.so.3 ln -s /opt/dell/srvadmin/oma/bin/libxmlsup32.so.2 /usr/lib/libxmlsup32.so.2 </pre>

[Admin]

Now omreport works but omreport chassis temps gives nothing and omreport -? gives Error! User has insufficient privileges to run command. (even as root)

[Admin]

\o/ [solved] with echo '/opt/dell/srvadmin/oma/bin/'>>/etc/ld.so.conf.d/omsa.conf ; ldconfig ; srvadmin-services.sh restart (thanks to Rainer Traut over on lists.us.dell.com/pipermail/linux-poweredge/2009-July/… ) (before I found that I reinstalled the dell repo and srvadmin-all)

[Chris_K]

I noticed perl-IO-Compress came down fine later in the day yesterday, so it looks like they got that one sorted out as well

[Chris_K]

Great tip! I wasn't aware of that option. Ironically, I'm in a similar situation again... I'll give this a shot.