Installing Red Hat Linux Applications

Installing with rpm

To install an RPM archive file with the rpm command that is not yet installed on your system, most people generally use the same options they would if they were upgrading (the -U option). Here's an example of a command line you could use to install a new RPM package.

# rpm -U [options] package

Package is the name of the RPM archive file. This package may be in the current directory, on a mounted CD (for example, /mnt/cdrom/RedHat/RPMS/whatever.rpm), or on an accessible FTP site (for example, ftp://sunsite.unc.edu/pub/Linux/games/strategy/galaxis-1.5-1.i386.rpm).

# rm -f /var/lib/rpm/__db*
# db_verify /var/lib/rpm/Packages
# rpm --rebuilddb

Along with the -U option, you can use the following options to get feedback during a new installation:

• -vv — Prints debugging information during installation. This is a good way to see everything that happens during the install process. (This output can be long, so you may want to pipe it to more.)

• -h — Prints 50 hash marks (#) as the package unpacks. The intent is to see the progress of the unpacking process (so you can tell if the program is still working or stalled).

• -percent — Prints the percentage of the total package that has been installed throughout the install process.

Before installing a package, rpm checks to make sure that it is not overwriting newer files or installing a package that has dependencies on other packages that are not installed. The following install options can be used to override conditions that may otherwise cause the installation to fail:

• --force — Forces the contents of the current package to be installed, even if the current package is older than the one already installed, contains files placed there by other packages, or is already installed. (This is the same as using the oldpackage, replacefiles, and replacepkgs options.)

• --oldpackage — Forces the package to be installed, even if the current package is older than the one already installed.

• --replacefiles — Forces files in this package to be installed, even if the files were placed there by other packages.

• --replacepkgs — Forces packages in this archive to be installed, even if they are already installed on the system.

• --nodeps — Skips package dependency checks and installs the package, even if packages it depends on are not installed.

• --ignorearch — Forces package to be installed, even if the binaries in the package don't match the architecture of your host computer.

• --excludedocs — Excludes any man pages, texinfo documents, or other files marked as documentation.

• --ignoreos — Forces package to be installed, even if the binaries in the package don't match the architecture of your operating system.

The following is a simple rpm command line used to install an RPM archive:

# rpm -U RealPlayer-8.0-1.i386.rpm

I personally like to see some feedback when I install something (by default, rpm is suspiciously quiet when it succeeds). Here is what the command looked like when I added the -vv option to get more verbose feedback, along with some of the output:

# rpm -Uvv RealPlayer-8.0-1.i386.rpm
D: ============== RealPlayer-8.0-1.i386.rpm
D: Expected size:      4978643 = lead(96)+sigs(100)+pad(4)+data(4978443)
D:   Actual size:      4978611
D: RealPlayer-8.0-1.i386.rpm: MD5 digest: OK (f8080e7c3c32eacc6912a5afb364479a)
D:      added binary package [0]
D: found 0 source and 1 binary packages
D: opening  db environment /var/lib/rpm/Packages joinenv
       .
       .
D: installing binary packages
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages create mode=0x42
       .
       .
       .
D: closed   db index       /var/lib/rpm/Basenames
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages

From this output, you can see that rpm finds one binary package in this archive, verifies the checksum, opens the RPM database, installs the packages, and closes the database when done. Another way to verify that the install is actually working is to add the -h option, as follows:

# rpm -Uvh RealPlayer-8.0-1.i386.rpm
RealPlayer  ##################################################

With the -h option, rpm chugs out 50 hash marks (#) until the package is done installing. As you can see, when everything goes well, installing with rpm is quite simple. Some problems can occur, however. Here are a couple of them:

• Package dependencies errors — If the package you are installing requires an additional package for it to work properly, you will see an error noting the missing package. You should get and install that package before trying your package again. (You can override the failure with install options described above, but I don't recommend that because your package may not work without the dependent package.)

• Nonroot user errors — If rpm -U is run by someone who is not the root user, the command will fail. The output will indicate that the /var/lib/rpm database could not be opened. Log in as root user and try again.

Upgrading packages with rpm

The upgrade option (-U) with rpm can, as you might expect, also be used to upgrade existing packages. The format is the same as described above:

# rpm -U [options] package

One issue when upgrading is installing an older version of a package. For example, if you install a new version of some software and it doesn't work as well, you will want to go back to the old version. To do this, you can use the --oldpackage option as follows:

# rpm -U --oldpackage AnotherLevel-0.7.4-1.noarch.rpm

If a later package of this name already exists, it is removed and the older version is installed.

Freshening packages with rpm

An option that is similar to the upgrade (-U) option is the freshen (-F) option. The main difference between the two is what happens if the RPM you are updating or freshening is not already installed on your Red Hat Linux system. With -U, the package is installed if it is not already installed; with -F, the package is not installed if it is not already installed.

A great use for freshen is when you have a directory full of updated RPM files that you want to install on your system. But, you only want to update those packages that are already installed. In other words, there may be a lot of RPMs in the directory you don't want. Freshen lets you just update the package you already have.

Let's say that you downloaded a directory of RPMs and you want to selectively freshen the ones you have installed. With the directory of RPMs as your current directory, you could type:

# rpm -Fhv *.rpm

Packages already installed are updated with the new RPMs. All other RPMs are skipped.

Removing packages with rpm

If you no longer want to use a package (or you just want to recover some disk space), use the -e option to remove a package. In its simplest form, you use rpm with the -e option as follows:

# rpm -e package

If there are no dependencies on this package, it is silently removed. Before you remove a package, however, you may want to do a quick check for dependencies. The -q option is used for a variety of query options. (Checking for dependencies isn't necessary because rpm checks for dependencies before it removes a package. You may want to do this for your own information, however.) To check for dependencies, do the following:

# rpm -q --whatrequires package

If you decide to remove the package, I recommend using the -vv option with rpm -e. This lets you see the actual files that are being removed. I also suggest that you either direct the output to a file or pipe it to more because the output often runs off the screen. For example:

# rpm -evv jpilot | more

This example removes the jpilot package and shows you the files that are being removed one page at a time. (Press the Spacebar to page through the output.)

Other options that you can run with rpm -e can be used to override conditions that would prevent the package from being removed or to prevent some processing (such as not running preuninstall and postuninstall scripts). Three of those options are as follows:

• --nodeps — Uninstall the package without checking for dependencies.

• --noscripts — Uninstall the package without running any preuninstall or postuninstall scripts.

• --notriggers — Uninstall the package without executing scripts that are triggered by removing the package.

If you feel nervous about boldly removing a package, you can always run the uninstall in test mode (--test) before you do the real uninstall. Test mode shows you everything that would happen in the uninstall without actually uninstalling. (Add the --vv option to see the details.) Here's an example:

# rpm -evv --test jpilot | more
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
    .
    .
    .
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages

If the results look fine, you can run the command again, without the --test option, to have the package removed.

Querying packages with rpm

Using the query options (-q) of rpm, you can get information about RPM packages. This can be simply listing the packages that are installed or printing detailed information about a package. Here is the basic format of an rpm query command (at least one option is required):

# rpm -q [options]

The following are some useful options you can use with an rpm query:

• -qa — Lists all installed packages.

• -qf file — Lists the package that owns file. (The file must include the full path name or rpm assumes the current directory.)

• -qi package — Lists lots of information about a package.

• -qR package — Lists components (such as libraries and commands) that package depends on.

• -ql package — Lists all the files contained in package.

• -qd package — Lists all documentation files that come in package.

• -qc package — Lists all configuration files that come in package.

To list all the packages installed on your computer, use the -a query option. Because this is a long list, you should either pipe the output to more or, possibly, use grep to find the package you want. The following command line displays a list of all installed RPM packages, and then shows only those names that include the string of characters xfree. (The -i option to grep says to ignore case.)

# rpm -qa |grep -i xfree

If you are interested in details about a particular package, you can use the rpm -i query option. In the following example, information about the dosfstools package (for working with DOS file systems in Linux) is displayed:

# rpm -qi dosfstools
Name        : dosfstools             Relocations: (not relocateable)
Version     : 2.8                              Vendor: Red Hat, Inc.
Release     : 5          Build Date: Tue 18 Feb 2003 11:08:21 PM PST
Install Date: Sat 09 Aug 2003 02:15:35 PM PST
Build Host  : daffy.perf.redhat.com
Group       : Applications/System Source RPM:dosfstools-2.8-6.src.rpm
Size        : 73278                            License: GPL
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : Utilities for making and checking MS-DOS FAT
              filesystems on Linux.
Description :
The dosfstools package includes the mkdosfs and dosfsck utilities,
which respectively make and check MS-DOS FAT filesystems on hard
drives or on floppies.

To find out about a package's contents, you can use the -l (list) option with your query. The following example shows the complete path names of files contained in the xpilot package:

# rpm -ql dosfstools | more
/sbin/dosfsck
/sbin/fsck.msdos
/sbin/fsck.vfat
/sbin/mkdosfs
/sbin/mkfs.msdos
/sbin/mkfs.vfat
/usr/share/man/man8/dosfsck.8.gz
    .
    .
    .

Would you like to know how to use the components in a package? Using the -d option with a query will display the documentation (man pages, README files, HOWTOs, and so on) that is included with the package. If you are having trouble getting your X Window System running properly, you can use the following command line to find documents that may help:

# rpm -qd XFree86 | more
/usr/X11R6/man/man1/XFree86.1x.gz
/usr/X11R6/man/man1/Xmark.1x.gz
/usr/X11R6/man/man1/Xserver.1x.gz
/usr/X11R6/man/man1/appres.1x.gz
/usr/X11R6/man/man1/atobm.1x.gz
/usr/X11R6/man/man1/bdftopcf.1x.gz
     .
     .
     .

Many packages have configuration files associated with them. To see what configuration files are associated with a particular package, use the -c option with a query. For example, this is what you would type to find configuration files that are used with the ppp package:

# rpm -qc ppp
/etc/pam.d/ppp
/etc/ppp/chap-secrets
/etc/ppp/options
/etc/ppp/pap-secrets

If you ever want to know which package a particular command or configuration file came from, you can use the -qf option. In the following example, the -qf option displays the fact that the chgrp command comes from the fileutils package:

# rpm -qf /bin/chgrp
fileutils-4.1-4

Verifying packages with rpm

If something in a software package isn't working properly, or if you suspect that your system has been tampered with, the verify (-V) option of rpm can help you verify installed software against its original software package. Information about each installed package is stored on your computer in the RPM database. By using the verify option, you can check whether any changes were made to the components in the package.

Various file size and permissions tests are done during a verify operation. If everything is fine, there is no output. Any components that have changed from when they were installed will be printed along with information indicating how they were changed. Here's an example:

# rpm -V ppp
S.5....T c /etc/ppp/chap-secrets
S.5....T c /etc/ppp/options
S.5....T c /etc/ppp/pap-secrets

This output shows that the ppp package (used to dial-up a TCP/IP network such as the Internet) has had three files changed since it was installed. The notation at the beginning shows that the file size (S), the MD5 sum (5), and the modification time (T) have all changed. The letter c shows that these are all configuration files. By reviewing these files to see that the changes were only those that I made to get PPP working, I can verify that the software is okay.

The indicators that you may see when you verify the contents of a configuration file are:

• 5 — MD5 Sum — An MD5 checksum indicates a change to the file contents.

• S — File size — The number of characters in the file has changed.

• L — Symlink — The file has become a symbolic link to another file.

• T — Mtime — The modification time of the file has changed.

• D — Device — The file has become a device special file.

• U — User — The user name that owns the file has changed.

• G — Group — The group assigned to the file has changed.

• M — Mode — If the ownership or permission of the file changed.

  Tip?

  A utility is available to browse the contents of RPM files from Windows. With the rpmbrowser.exe utility, you can list and extract files from an RPM distribution. This utility is available from winsite.com (search for rpmbrowser from www.winsite.com/search).

Installing software in SRPMS format

To install a source package from CD #3 or the Red Hat Linux source CD, do the following:

1. Insert a Red Hat Linux source CD into the CD-ROM drive. It should mount automatically. (If it doesn't, type mount /mnt/cdrom in a Terminal window as root.)

2. Change to the source directory on the CD. For example:

   # cd /mnt/cdrom/SRPMS
   

3. Choose the package you want to install (type ls to see the packages) and install it using the following command:

   # rpm -iv packagename*.src.rpm
   

   (Replace packagename with the name of the package you are installing.) The source is installed in the Red Hat Linux source tree (/usr/src/redhat). Spec files are copied to /usr/src/redhat/SPECS.

4. Change to the SPECS directory as follows:

   # cd /usr/src/redhat/SPECS
   

5. Unpack the source code as follows:

   # rpm -bp packagename*.spec
   

6. The package's source code is installed to the /usr/src/redhat/BUILD/package directory, where package is the name of the software package.

7. You can now make changes to the files in the package's BUILD directory. Read the README, Makefile, and other documentation files for details on how to build the individual package.

Installing software in gzip/tar format

Here are some generic instructions that you can use to install many Linux software packages that are in gzip/tar format:

1. Get the source code package from the Internet or from a CD distribution and copy it into an empty directory (preferably using a name that identifies the package).

2. Assuming the file is compressed using gzip, uncompress the file using the following command:

   # gzip -d package.tar.gz
   

   The result is that the package is uncompressed and the .gz is removed from the package name (for example, package.tar).

3. From the resulting tar archive, run the tar command as follows:

   # tar xvf package.tar
   

   This command extracts the files from the archive and copies them to a subdirectory of the current directory.

4. Change directories to the new subdirectory created in Step 3, as follows:

   # cd package
   

5. Look for a file called INSTALL or README. One of these files should give you instructions on how to proceed with the installation. In general, the make command is used to install the package. Here are a few things to look for in the current directory:

   If there is a Make.in file, try running:

   # ./configure –prefix=/usr
   # make all
   

   If there is an Imake file, try running:

   # xmkmf –a
   # make all
   

   If there is a Make file, try running:

   # make all
   

After the program is built and installed, you may need to do additional configuration. You should consult the man pages and/or the HOWTOs that come with the software for information on how to proceed.

To try out this procedure, I downloaded the whichman package, which includes utilities that let you find manual pages by entering keywords. The file I downloaded, whichman-2.2.tar.gz, was placed in a directory that I created called /usr/sw/which. I then ran the gzip and tar commands, using whichman-2.2.tar.gz and whichman-2.2.tar as options, respectively.

I changed to the new directory, cd /usr/sw/which/whichman-2.2. I then listed its contents. The README file contained information about the contents of the package and how to install it. As the README file suggested, I typed make, and then make install. The commands whichman, ftwhich, and ftff were installed in /usr/bin. (At this point, you can check the man page for each component to see what it does.)

The last thing I found in the README file was that a bit of configuration needed to be done. I added a MANPATH variable to my $HOME/.bashrc to identify the location of man pages on my computer to be searched by the whichman utility. The line I added looked like this:

export
MANPATH=/usr/share/man:/usr/man/man1:/usr/X11R6/man:/usr/share/doc/samba-
2.2.3a/docs

In case you are wondering, whichman, ftwhich, and ftff are commands that you can use to search for man pages. They can be used to find several locations of a man page, man pages that are close to the name you enter, or man pages that are located beneath a point in the directory structure, respectively.