Talk:RPM Commands
Contents
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.
rpm commands
rpm commands (§ - package must be installed already)
reference: http://www.rapierbit.org/linux/howto.html
* install: rpm -i[hv] name_of_rpm.ppc.rpm * upgrade: rpm -U[hv] name_of_rpm.ppc.rpm * uninstall: rpm -e name_of_rpm * get version number: rpm -q name_of_rpm * get package info: rpm -qi name_of_rpm § * find out which packages are installed: rpm -qa * discover package contents: rpm -qpl name_of_rpm.ppc.rpm * discover package dependencies: rpm -qR name_of_rpm * find out which rpm a file goes with: rpm -qf name_of_file § * find out which rpm provides a particular file: rpm -q --whatprovides name_of_file § * uninstall all packages that start with this-: rpm -qa | grep "^this-" | xargs rpm -e * uninstall all packages that contain that: rpm -qa | grep "that" | xargs rpm -e
swup
Match(es) on 'libstdc++.so.6' in trustix-2.2: Got 0 matches from '--search-package' Got 0 matches from '--search-file' Got 0 matches from '--search-resource'
Match(es) on 'libstdc++.so.6' in trustix-3.0:
Got 0 matches from '--search-package'
Match(es) from --search-file:
gcc-c++-runtime (3.4.4-3tr): /usr/lib/libstdc++.so.6
gcc-c++-runtime (3.4.4-3tr): /usr/lib/libstdc++.so.6.0.3
Got 2 match(es) from '--search-file'
Match(es) from --search-resource:
libstdc++.so.6
Got 1 match(es) from '--search-resource'
Match(es) on 'libstdc++.so.6' in community-2.2:
Got 0 matches from '--search-package'
Got 0 matches from '--search-file'
Got 0 matches from '--search-resource'
Match(es) on 'libstdc++.so.6' in community-3:
Got 0 matches from '--search-package'
Got 0 matches from '--search-file'
Got 0 matches from '--search-resource'
