Difference between revisions of "Talk:RPM Commands"

Revision as of 19:46, 31 May 2007

tzdata >= 2003a is needed by glibc

You need to upgrade all the rpms in the list at once. rpm -Uvh glibc*.rpm tzdata*.rpm

rpm -Uvh glibc*.rpm tzdata*.rpm          
Preparing...                ########################################### [100%]
   1:glibc-devel            ########################################### [ 25%]
   2:tzdata                 ########################################### [ 50%]
   3:glibc                  warning: /etc/ld.so.cache created as /etc/ld.so.cache.rpmnew
########################################### [ 75%]
   4:glibc-locales          ########################################### [100%]

Please edit the file /etc/locales.conf to manipulate which locales
will be generated. Then issue the command "/usr/sbin/locales-gen"

Finding out what RPM file has the dependency

error: failed dependencies:
       libstdc++.so.6   is needed by aspell-0.60.4-1tr
       libstdc++.so.6   is needed by aspell-libs-0.60.4-1tr

so what rpm contains libstdc++.so.6?

Peter's RPM Notes

Reference: http://www.dirac.org/linux/rpm.html

Suppose you find a new package called newpackage-1-50.rpm. You'd like to find out what it does. To learn about it:

   rpm -qip newpackage-1-50.rpm 

and the output may look something like:

   Name : newpackage Distribution: (none) Version : 1 Vendor: (none) Release : 50 Build Date: Mon May 24 19:59:25 1999 Install date: (not installed) Build Host: satan.ucdavis.edu Group : new packages Source RPM: newpackage-1-50.src.rpm Size : 3080130 License: GNU Summary : does neat stuff Description : This package does some really great stuff that you have GOT to have! 

You think to yourself "hmmm, I'd like to install this package". To make sure that you haven't already installed the package, you type:

   rpm -q newpackage 

and the system responds with "Package newpackage is not installed". If you're the cautious type, you'd first like to find out what files this rpm installs (always a good idea) onto your hard drive. To do this:

   rpm -qpl newpackage-1-50.rpm 

and the output would look something like: /etc/foobar /usr/doc/newpackage /usr/doc/COPYING /usr/games/newpackage /usr/games/newpacage/newpackage /usr/lib/newpackagelib.so.1

OK, so now we know what's going to be put on our hard drive. Now you install the package with: rpm -i newpackage-1-50.rpm

Suppose you get some error messages like "failed dependency". If you know what you're doing, you can force the installation to proceed by:

   rpm -i --nodeps newpackage-1-50.rpm

Now you download an update to newpackage, called newpackage-1-51.rpm. Make sure that the old package is already installed (it's been a long time; you've forgotten whether you installed it or not), type: rpm -q newpackage

and the system responds with newpackage-1-50

Suppose you wanted more information about the package (what it does, when you installed it, etc). Simply do:

   rpm -qi newpackage-1.50

And you see output similar to the -qip output above. If it hadn't been installed, rpm would've simply have said "Package newpackage-1-50.rpm is not installed". One thing to note. This last command checks specifically for newpackage version 1, release 50. If you wanted to check for *ANY* version of newpackage, you'd simply type rpm -qi newpackage Now to upgrade your 1-50 version of newpackage to the 1-51 version, type: rpm -U newpackage-1-51.rpm

If you get error messages, and you know what you're doing, you can force the upgrade to install by specifying

   rpm -U --nodeps newpackage-1-51.rpm.

New Scenario

Suppose you deleted file /etc/foobar by accident. You want to find out which rpm package installed it so you can reinstall it somehow. You *think* foobar was part of the gcc package. To make sure that all the files that were installed by the gcc installation are present and accounted for, type:

   rpm -V gcc

And the system doesn't print anything out which means that all the files placed on your hard drive from the gcc installation are where they ought to be (this is a prime example of "no news is good news". Dang. You smack your forehead as you realize that /etc/foobar was probably part of the newpackage-rpm installation you did a few months earlier. So you type:

   rpm -V newpackage

(or rpm -V newpackage-1-51, but the first method is safer since it's valid for ANY version of newpackage that you might have installed). This time, your linux box responds with: missing /etc/foobar

By the way, what would happen if you really couldn't figure out which package /etc/foobar belonged to? There's a way to verify that the files from ALL your installed rpm's are where they ought to be.

   rpm -Va

This makes sure that the files from each and every installed package are present on your system. It'll take a long time to finish...

Now, suppose we wanted to fix newpackage-1-51. One way would be to remove the package and then reinstall it:

   rpm -e newpackage rpm -i newpackage-1-51

A few things could go wrong. When we try to remove the package, rpm can complain that if we removed the package, it would 'break' other packages that require newpackage to be installed. Since we're going to be reinstalling newpackage anyhow, it would be safe to remove newpackage, dependency failure or not. To force the removal:

   rpm -e --nodeps newpackage

But then you really do need to install newpackage-1.51. During the installation attempt, you may get failed dependency errors again. Again, if you know what you're doing, you can force the installation by using

   rpm -i --nodeps newpackage-1-51.

There's another possibility. Since you only want a single file, you can extract that single file directly from the rpm into a temp directory and put it in place by hand. The first step is to make a temp directory and cd into it. mkdir temp cd temp

Now we want to "un-rpm" the rpm.

   rpm2cpio newpackage-1-51.rpm | cpio -i --make-directories

the --make-directories switch means to put all the files relative to your temp directory, rather directly into the filesystem. Now if you do an ls, you'll see: etc/ usr/

and these directories will contain exactly the files listed at the beginning of this document. etc will contain foobar. usr will contain the files doc, bin and lib, and so on. Now you can simply move foobar back to it's location: cp ./etc/foobar /etc/foobar

and you're done. To rebuild your rpm database, type

   rpm --rebuilddb

and your hard drive whirs. I have no idea what it does (specifically), but I get a warm fuzzy feeling when I do it. What can we learn from rpm names?

Suppose you have an rpm by the name of XFree86-3.3.1-14.i386.rpm Package name: XFree86 Version number: 3.3.1 (this is NOT dependent on vendor) Release number: 14 (this is vendor specific!!) Architecture: i386 (this package works on any 80386 compatible system)

It's possible that architecture is "noarch" which means you can install it on a linux system running on PC, sparc, alpha, etc. Can I use an RPM from one distribution with another distribution?

This is a very tricky question. The answer is certainly it depends. There's a couple of `gotchas' involved. Here are a few of them.

Suppose you want to install an RPM for a console mp3 player, like mp3blaster. This application requires that a library called `ncurses' be somewhere on your system. When you install an mp3blaster RPM, the RPM will make sure that the package for ncurses is installed already.

The problem is that the ncurses package may be called ncurses.rpm by Suse and libcurses.rpm by Redhat. Suppose you have Redhat on your computer and want to install an mp3blaster package that belongs to Suse. The package will look for ncurses.rpm on your system, not find it and refuse to install, even though you do have the ncurses library on your system. The problem is that the rpm that you have installed that provides ncurses is named something different. Note that you can force the package to install. This may or may not work.

Another problem can arise when a package expects a file at a certain location. For example, the startup script in Redhat are in /etc/rc.d/, but in Suse they're in /sbin/rc.d/. Suppose you have Redhat on your computer and want to install a Suse package and the package needs to add a startup script on your system. Since the startup script locations are different, you're out of luck.

This type of problem may be fixable by using strace, but frankly, this is a very advanced technique.