Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to upgrade MySQL from 4.1.20 up to 5.1.39. v4.1 was installed via RPMs with no issue, but attempting to upgrade throws up several warnings which appear erroneous, such as:

# rpm --upgrade MySQL-client-5.1.39-0.glibc23.i386.rpm
warning: MySQL-client-5.1.39-0.glibc23.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
error: Failed dependencies:
        libncursesw.so.5 is needed by MySQL-client-5.1.39-0.glibc23
#

Even though I have it installed at /usr/lib/libncurses.so.5

I'm also getting:

# rpm --upgrade MySQL-server-5.1.39-0.glibc23.i386.rpm
warning: MySQL-server-5.1.39-0.glibc23.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
error: Failed dependencies:
        perl(DBI) is needed by MySQL-server-5.1.39-0.glibc23
#

even though the reported version is 1.609:

# perl -M'DBI 999' -e1
DBI version 999 required--this is only version 1.609.

How can I make RPM see that they're installed? Or is now the time to revert to building from source?

EDIT: For the record, this is a fairly old Redhat box (i686, although I was trying the i386 RPMs)

share|improve this question

3 Answers 3

up vote 2 down vote accepted

Some questions/comments:

  • Which OS are you using?
  • Which arch? If you've got a 64-bit OS with 64-bit ncurses it won't fit to this 32-bit MySQL rpm.
  • From where did you get the rpm? I guess this is the vanilla version from mysql.com. Did you check their system requirements? Did you pick the right package for your distribution/OS? See http://dev.mysql.com/downloads/mysql/5.1.html for packages for all supported OSes. Make sure to match both arch and OS version!
  • libncursesw.so.5 != libncurses.so.5
  • What's the result of the command rpm -qf /usr/lib/libncurses.so.5 ? This will shown from where you've got your libncurses.so.5 file. You could then use rpm -qlv <PKG> to check the contents of this package for libncursesw.so.5.
  • I recommend to get the MySQL version of your OS distribution instead of a version from a 3rd-party because the package dependencies will be unproblematic.
  • I recommend to use yum/apt-get instead of rpm directly if you are not very proficient with rpm because it will resolve the required dependencies automatically for you.
  • rpm does not look at the installed files on your harddisk for dependency resolution. It only looks at the installed rpms (registered in rpm's own db). This means to meet a dependency you have to install the right rpm - it's not sufficient to install the correct files without rpm.
share|improve this answer
    
I think that last point is the most pertinent - at least DBI was installed via cpan :( –  Rowland Shaw Nov 1 '09 at 18:43
    
This is how people get into 'RPM hell.' If you are going to use a distro with a package manager, ALWAYS install via a package (even if you have to make them yourself, see cpan2rpm for cpan packages.) And don't mix packages from different distributions (or different versions of your distribution.) That will just cause you more issues down the road. I like package managers, but you have to learn how to create those packages for it to be truly effective. –  toppledwagon Nov 1 '09 at 20:43

Your dependancy database is messed up.

If using yum try:

yum clean all

If not, try:

rpm --rebuilddb

If that still fails, you could try rebuilding the DB by hand:

http://www.informatimago.com/linux/rpm-rebuilddb.html

Disclaimer: I have not tested the steps in this howto, so like anything you find on the net, proceed with caution. There may be parts of the steps which are out of date with modern versions of rpm tool set.

share|improve this answer
    
Well, I disagree. Nothing indicates that his rpm database is messed up! These are just unresolved dependencies errors. –  knweiss Nov 1 '09 at 14:37
    
My box is too old to come with yum (or apt-get for that matter) –  Rowland Shaw Nov 1 '09 at 18:47
    
Yet another commentator who wants to pretend that things I see are not true. It is common, for example, on Redhat Enterprise 5.* to see bogus dependency errors just like the OP's which are quickly resolved by running 'yum clean all' and then running 'yum update' again. It happens in about 30% of the updates I run, say from 5.2 to 5.4 RHEL. I'm involved with the administration of 46 RHEL servers at the moment. No yum? Running old version of Redhat? Here is a link to a Redhat KB item on how to rebuild the RPM database for older Redhat versions: kbase.redhat.com/faq/docs/DOC-6904 –  labradort Nov 1 '09 at 20:18
    
There are situations where a yum clean all helps but I'm pretty sure that this is not one of it. BTW: Often there are simply unresolved dependencies in a yum repo and yum get's blamed if there are subsequent errors. Did you already try to verify your yum repo with "repoclosure" (from the yum-utils package)? Give it a try and make sure all dependencies of all packages in the repo are fulfilled. –  knweiss Nov 1 '09 at 21:35

If you're using CentOS or RedHat i'd recommend to use mysql packages from rackspace's iuscommunity repository. You can find lastest versions of mysql (5.1.39) and they are very stable.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.