Package Installation

The answer depends on what kind of package you downloaded. You can avoid many installation headaches if you download programs in the form of Red Hat binary packages *.rpm (that's the format I select if given a choice).

Installation of RedHat binary packages

If the program I want to install is a RedHat binary package (*.rpm), I can use either a command line, or a GUI utility. I like to use the command-line utility because it is fast and trouble-free. The RedHat package manager installation utility is called rpm . First I read the info on the package content (optional):

rpm -qpi my_new_file.rpm

This queries (mode "q", must be the first letter after the dash) the yet uninstalled package (option "p") so that it displays the info (option "i") which the package contains. If I want to install the program, I run (as root):

rpm -ihv my_new_file.rpm

The above command does the installation job. It runs rpm telling it to install the package (mode "i", must be the first letter after the dash) while printing to the screen more information than usual (option "h"=display "hashes" to show the unpacking progress, option "v" = be verbose). The contents of the package are distributed to the directories where they belong (rpm knows where they belong). After this installation, the program is ready to run, I just have to know the executable name and its location. If I have trouble finding the executable, this lists all the files that the package contains together with their destination directories:

rpm -qpl my_new_file.rpm

This queries (option "q") the yet uninstalled package (option"p") so that it displays the listing (option "l") of all the files the package contains.

The GUI front-ends to rpm are: gnopro (the old version, that comes with RH6.0 is confusing, but newer versions are much improved), kpackage (available only with the more recent distributions), and the old glint (very slow, comes with RH5.2).

Troubleshooting. rpm is supposed to be an intelligent software package manager. If the installation fails I read the error message and may be able to figure what to do:

• Installation failed because I have an earlier version of the same package and the versions conflict. Solution: don't install, but "upgrade" the package.

rpm -Uvh my_new_file.rpm

• Installation failed because another package is needed first. I have to find the missing package and install it first, and then retry the installation. In extreme cases, I may choose to ignore the missing dependencies (I really should know what I am doing here else the software may malfunction):

rpm -ivh --nodeps my_new_file.rpm

or perhaps even:

rmp -ivh --nodeps --force my_new_file.rpm

Installation from a source-code tarball

If what I downloaded from the net is a Linux source code in the form of a compressed tarball (*.tar.gz or *.tgz), the installation procedure is longer and more troublesome than with the binary-only rpm. I typically install the program as root.

First, I change my current working directory to /usr/local:

cd /usr/local

Second, I decompress the tarball that I downloaded from the Internet:

tar -xvzf /home/the_dir_where_the_tarball_is/my_tarball.tar.gz

This extracts (option "x") the contents of the *.tar.gz (or *.tgz) tarball, unzips it (option "z"), while talking to me more than usual (option "v" = verbose). Please note that the option "f" means "file", so the filename must immediately follow the letter "f". The contents of the tarball are extracted into a subdirectory which tar creates under my current working directory, which in the typical case is /usr/local/ . The tarball knows what the new subdirectory should be called.

If the tarball is not compressed (e.g., *.tar), I may use:

tar -xvf /home/the_dir_where_the_tarball_is/my_tarball.tar

Third, I have to figure how the new directory is called, then I cd into it:

dir

cd the_new_program_subdir

Since some of the directories have long names, I use the great autocompletion option to save on typing--I just type the first few letters and then press <TAB> .

Fourth, most programs are compiled by executing these three commands:

./configure

make

make install

The above commands can take some time to complete (1 min? 0.5 h?). If any of them fail, it might be an idea to read the README or INSTALL or whatever info is provided with the new program. Some programs may require customization of the environment (e.g. definition of their path) or installation of an additional library, or yet something else. It can sometimes be a pain. Very simple programs might not need the "./configure" or/and "make install" step, in which case "make" alone will do.

Fifth, if everything goes well, I find the new executable which I just compiled. The names of executables display in green when running this command:

ls --color

Now, I can run the executable, for example:

./the_executable

Some programs automatically install the executable to /usr/local/bin, so I may want to try:

/usr/local/bin/the_executable

Sixth, if I plan to run the program more often, I create a symbolic link to the executable from the directory /usr/local/bin :

cd /usr/local/bin

ln -s /usr/local/the_new_program_subdir/the_executable

This way, the executable (actually, a symbolic link to it) is on my PATH and it can be run by simply typing its name (no need to type the full path to the executable any more). Some programs will install the executable (or a link to it) in a "bin" directory in which case you skip the last step.

Installation from source code rpm package

There are also programs distributed as "source code rpm" packages. They require installation of the *.rpm package with the "rpm" utility as described in the first part of this chapter. But since the "rpm" installs the source code (typically in the C language source code), I then have to compile the source code by executing the same: "./configure ; make ; make install" sequence as for the source code distributed as tarballs (see the previous answer).