When installing and/or upgrading packages using the /usr/bin/rpm command you have several choices depending on the exact outcome desired and the pre-existing situation.
First one should be aware of one of the RPM rules that is the main factor in this choice, namely "A file can only be 'owned' by a single RPM package". As with all rules in the UNIX/Linux it is possible to override this rule, but you get to keep all the pieces when stuff breaks.
Because of this rule, for the vast majority of packages you might install, you can only have one version installed.
For example, lets say you have two RPMs for the Apache web server.
httpd-2.0.54-10.3
httpd-2.2.0-5.1.2
(the package names come from Fedora Core v4 and v5 respectively).
You can examining the packages (before installation) and see what files are contained. In this case we'll just look at what files have "sbin" in their path since the complete list is over 300 files.
First the package for Apache version 2.0:
$ rpm -qlp httpd-2.0.54-10.3*rpm | grep sbin
/usr/sbin/apachectl
/usr/sbin/httpd
/usr/sbin/httpd.worker
/usr/sbin/rotatelogs
/usr/sbin/suexec
And for Apache version 2.2:
$ rpm -ql httpd-2.2.0-5.1.2 | grep sbin
/usr/sbin/apachectl
/usr/sbin/htcacheclean
/usr/sbin/httpd
/usr/sbin/httpd.worker
/usr/sbin/httxt2dbm
/usr/sbin/rotatelogs
/usr/sbin/suexec
Out of the 300+ files if a single file is the same you can't have both packages installed at the same time. Really the constraint isn't the two Apache RPMs, but the entire set of RPMs that are installed or will be installed on a box. No files can "conflict" (be the same).
With this rule covered, now what RPM options are available and when would one use them. Pretty much you will always use the "vh" options to get verbose output and hash (#) marks. But of the primary action options are "-i", "-U", and "-F".
* "-i". Performs an installation without removing (aka upgrading) any older version of the package. If you have an older version of the package installed, most likely THE COMMAND WILL FAIL because of overlapping files (see the Apache example above). So, for the most part, you can only use "-i" if you know ahead of time that you don't have an older version of the package already installed.
This begs the question, "When can I have two versions of a package installed simultaneously?". There are two situations, one fairly common and the other not so common.
* With the "kernel" RPM package. It turns out that every file provided by the kernel RPM package has the kernel version string somewhere in the full path, for example:
/lib/modules/2.6.15-1.2054_FC5/kernel/arch/i386/crypto/aes-i586.ko
Because of that you CAN have multiple kernel RPM packages installed at the same time, and you might actually WANT to. You might want to because the kernel is very critical to the operation of the system and if you install a new kernel version, and for whatever reason (bad driver, bug, etc) it doesn't work properly or won't boot, by having your old "known good" kernel installed you can easily recover (reboot and select the old kernel from the GRUB menu).
* The other case is when trying to run an old binary you discover it is requires /usr/lib/libfoo.so.1 and you have /usr/lib/libfoo.so.2 installed. Like the kernel RPM, most (but not all), library packages have the version string embedded in the file name and therefore don't conflict.
By using "-i" you can install libfoo-1.0.18.i386.rpm alongside libfoo-2.0.22.i386.rpm.
Finally, for the sake of completeness another related question "How can I have two packages installed where both are supplying a file with same full path?". Here are some example scenarios:
* sendmail and postfix both trying to provide /usr/sbin/sendmail
* SUN Java, IBM Java, and GCJ trying to provide /usr/bin/java
* CUPS, LPRng both trying to provide /usr/bin/lpr
The answer is (as is often the case in computer science), don't have the files conflict and use an abstraction layer. This was first done by the Debian folks in the creation of the "alternatives" system, it is used very widely in Debian/Ubuntu for lots of different packages. Red Hat adopted it during the 7.x time frame but used it just with MTAs (sendmail, postfix) and printing subsystems. SUSE has now adopted it with version 10.0 but only for Java packages from the jpackage project. The complete discussion of the alternatives system is beyond the scope of this blog post. We do have excellent coverage in our Linux training classes though.
* "-F". Performs an installation and removes (aka upgrades) any older version of the package if and only if you DO have an older version of the package installed. This option I like to call the "upgrade only" option. It is relic of the olden days of updating a Linux box with errata. Back then you update your system with the updates by:
1. Download all available updates (using ftp and mget *rpm) into a local directory.
2. In that directory run "rpm -Fvh *rpm".
This way you wouldn't install any new software packages that happened to have an update and instead you would just update the packages you did have installed.
Today we keep our systems current with smarter methods such as "yum -y update, you, up2date, rug, etc".
* "-U". This option performs an install if you don't have an older version already installed, and an upgrade if you do. I call it the "install or update as needed" option.
So to answer the question, "What RPM option does Dax Kelson use to install or upgrade RPM packages?" the answer is, "I try not to use /usr/bin/rpm unless I'm installing packages I've created myself or manually downloaded." Instead to install software I use a front end that figures out and downloads the dependencies automatically for me. For example:
* yum install packagename ...
* yast -i packagename ...
* up2date packagename ...
In the case when I've created my own RPM or done a manual download of a RPM package I like to use the "-U" option. This way RPM does the right thing (install or upgrade as needed) for me and I don't have to keep track of mentally if I already have the package installed.
Leave a comment