To get the most out of your Linux system, such as adding features, getting rid of potential bugs, and ensuring it is reasonably free of security holes, it is a good idea to keep your server -- including the Linux kernel, modules, and user applications -- upgraded. At times it may also be necessary to upgrade hardware components such as a larger hard drive. This chapter will address these issues.
The Red Hat distribution of Linux, including kernel, libraries, and applications are provided as RPM files. An RPM file, also known as a “package” is a way of distributing software so that it can be easily installed, upgraded, queried, and deleted. RPM files contain information on the package's name, version, other file dependency information (if applicable), platform (such as Intel or Alpha, etc.), as well as default file install locations.
The RPM utility was first developed by Red Hat and provided as an Open Source product as is common in the Linux community. Other developers picked it up and added extra functionality. The RPM method of packaging files has become popular and is used not only on Red Hat's but on some other distributions as well.
Popular Linux applications are almost always released as RPM files, usually in fairly short order. However, in the Unix world the defacto-standard for package distribution continues to be by way of so-called “tarballs”. Tarballs are simply files that are readable with the ``tar'' utility. Installing from tar is usually significantly more tedious than using RPM. So why would people choose to do so? Unfortunately, sometimes it takes a few weeks for developers to get the latest version of a package converted to RPM (many developers first release them as tarballs).
If you start installing or upgrading your system or applications with tar, your RPM database will become out-of-date and inconsistent. This isn't really a big deal (when I used Slackware, I used tar exclusively -- there was no other choice -- without too much discomfort), but wherever possible I try to be patient and wait until an RPM becomes available, or perhaps send a polite request to the developer of the package. (You can also build your own RPM files and distribute them to others, which is sometimes helpful to developers who don't have the ability or time to produce such files themselves.)
A really good place to check if a piece of software is available in RPM form is the RPM repository at http://rufus.w3.org/linux/RPM/. The repository provides indexed categories which can be helpful to locate a given RPM file, and contains pointers to thousands of such files.
To query a package, use ``rpm -q pkg-name'' (eg. ``rpm -q pine''). RPM will either tell you what version of the package is already installed, or that the package is not installed.
Assuming the package is installed already, and is an earlier version than the update package you downloaded (which it should be), then you should be able to apply the update with ``rpm -Uvh pkg-name''. If all goes well, the package will be automatically installed and immediately ready for use. If not, RPM will give you a pretty good reason (for example, perhaps a supporting package needs to be upgraded first). This may require a bit of thinking, but problems such as these are very straightforward to figure out.
If, on the other hand, the package is not yet installed, and you decide you wish to install it, type ``rpm -ivh pkg-name''. If there are any supporting packages that are required, RPM will tell you.
Sometimes, you will want to install a package that is only available in source format. In fact, unless you are installing packages from a trusted source (such as the Red Hat FTP site), you probably should install from source in case the binaries contain a trojan horse or other nasty thing (of course, a source RPM could also contain such a thing, but they are unlikely to because they would probably be exposed in short order by another developer).
The way to install a package from source is to specify the ``rebuild'' switch to the RPM utility. For example:
rpm -ivh --rebuild foo.src.rpm |
The above command would configure and compile the ``foo'' package, producing a binary RPM file in the ``/usr/src/redhat/RPMS/i386/'' directory (assuming you are using Linux on the Intel platform). You can then install the package as you normally would.
Finally, if you are having problems getting a source package to compile (perhaps you need to modify a makefile, or change a configuration option, etc.) you can use the following steps (again, illustrating our ficticious ``foo'' package example) to compile the source, build a new binary package, and then install from the binary package:
rpm -ivh foo.src.rpm cd /usr/src/redhat/SPECS pico -w foo.spec |
Make whatever changes you feel are needed to the ``.spec'' file, and then type:
rpm -ba foo.spec |
This will rebuild the package using whatever changes you have made to the ``.spec'' file. As above, the resultant binary RPM file will be located in ``/usr/src/redhat/RPMS/i386/'', and can be installed as you normally would.
You should look at the Red Hat documentation for more information on RPM. It is an extremely powerful tool that is worth learning in finer detail. The best source of information on RPM is ``Maximum RPM'', which is available in both book form, as well as in postscript format at http://www.rpm.org/maximum-rpm.ps.gz. (If you decide to print the postscript document, be advised that you'll need a lot of paper to do so!) There is a smaller guide, the ``RPM-HOWTO'', at http://www.rpm.org/support/RPM-HOWTO.html available as well.