Part 3 of the Linux Newbie Administrator Guide
3.5.1 How do I install a program I downloaded from the Internet?
(continued after the ads...)
OF REDHAT BINARY PACKAGES
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).
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:
(2) 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):
-ivh --nodeps my_new_file.rpm
or perhaps even:
rmp -ivh --nodeps --force my_new_file.rpm
FROM A SOURCE-CODE TARBALL
Second, I decompress the tarball that I downloaded from the net:
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:
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
Fourth, most programs are compiled by executing these three commands:
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:
Now, I can run the executable, for example:
Some programs automatically install the executable to /usr/local/bin, so I may want to try:
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
o 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 sourcecode distributed as tarballs (see the previous answer).
Next > FAQ: Startup Issues