The first part of this section describes how to install and manage applications using tools created for RPM archive files. Later in this section, you will learn how to build and install applications that come as source code packages.
The rpm command can be used to install any packages that are in RPM format. If you need to install RPM packages that are part of your Fedora Core distribution, you can use the Package Management window to add and remove packages instead of the rpm command. The Package Management window is described in Chapter 2. To upgrade existing packages, you can use the up2date command (described in Chapter 10) or yum command (described earlier in this chapter).
When you get an application that is packaged in RPM format, you typically get a single file. The command used to work with RPM package files is rpm. To manage RPM packages, the rpm command has options that let you list all the packages that are installed, upgrade existing packages to newer versions, and query packages for information (such as the files or documentation included with the package). There is also a verify option to check that all files that make up the package are present and unchanged.
The rpm command has the following modes of operation:
signature check (--checksig)
rebuild database (--rebuilddb)
fix permissions (--setperms)
set owners/groups (--setugids)
show RC (--showrc)
With these options, you can install RPM packages and verify that their contents are properly installed, correcting any problems that occur. You can also do special things, such as rebuild the RPM database and modify ownership. You must be logged in as the root user to add or remove packages. You may, however, list installed packages, query packages for information, or verify a package’s contents without root permission.
The following sections describe how to use rpm to install and work with your RPM applications.
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 DVD or CD (for example, /media/cdrw_dvdrom/Fedora/RPMS/whatever.rpm), or on an accessible FTP site (for example, ftp://sunsite.unc.edu/pub/Linux/games/strategy/galaxis-1.7-1.i386.rpm).
Interrupting rpm during a package installation can leave stale lock files and possibly corrupt the database. As a result, subsequent rpm commands may hang. If this happens, you can probably correct the problem by removing old database locks. If that doesn't work, you can also try checking whether the database is corrupt and, if so, rebuilding the RPM database. Rebuilding the database can tak a long time, so only do it if the other options don't clear up the problem. Here's how to remove lock files, check the database, and rebuild the database (as root user):
# rm -f /var/lib/rpm/__db* # db_verify /var/lib/rpm/Packages
Along with the -U option, you can use the following options to get feedback during a new installation:
-v — 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 the less command.) You can get more information by adding multiple -v options (for example, -vv).
-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.) Although it is dangerous to do so, people often use this option to override any issue that might cause the package install to fail (such as an older RPM).
--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. This option should be used with extreme caution! By not resolving dependencies properly, you can end up with broken software.
--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 like to see some feedback when I install something (by default, rpm is suspiciously quiet when it succeeds). Here is what the command looks like when I add 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  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.
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
Although there is a separate install option (-i), I recommend using the -U option whether you are doing a new install or an upgrade. With -U, the package installs in either case. So rpm -U always works (with one exception), while rpm -i fails if the package is already installed.
The exception is when you are installing kernel packages. Use -i when installing a new kernel or your old (and presumably, working) kernel will be removed and you could be stuck with an unbootable system!
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.
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 Fedora system. The -U can do either a fresh install or an upgrade. The -F will only do an upgrade (so if the package is not already installed, rpm -F will do nothing).
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 packages 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.
Again, note that you should not do freshens or upgrade on kernel packages, since it might cause your only working kernel to be removed when you add the new one.
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 the less command because the output often runs off the screen. For example:
# rpm -evv jpilot | less
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 | less 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.
You can use the query options (-q) of rpm to 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 list shows 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.
-qp [option] package — Query packages that are not yet installed. Using this option, along with other query options, allows you to query packages you have that are not yet installed.
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 less 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 xorg
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 : 13 Build Date: Tue 15 Jun 2004 06:12:03 PM CDT Install Date: Wed 2004 09:07:46 AM CDT Build Host : tweety.devel.redhat.com Group : Applications/System Source RPM:dosfstools-2.8-13.src.rpm Size : 70698 License: GPL Signature : DSA/SHA1, Tue 06 Jul 2004 11:41:38 AM CDT, Key ID da84cbd430c9ecf8 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 dosfstools package:
# rpm -ql dosfstools | less /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 xorg-x11 | less /usr/X11R6/man/man1/Xmark.1x.gz /usr/X11R6/man/man1/Xorg.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/bitmap.1x.gz /usr/X11R6/man/man1/bmtoa.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
Before you install a package, you can do the same queries on it that you would do on an installed package. This can be a great tool for finding information from a package while it is in your current directory, or even in a software repository. Here is an example of using the -qp option with -i to see the description of a package in a software repository:
# rpm -qp -i \ http://ayo.freshrpms.net/fedora/linux/1/i386/freshrpms/RPMS/blackbox-0.65.0-\ 8.1.fc1.fr.i386.rpm Name : blackbox Relocations: (not relocatable) Version : 0.65.0 Vendor: Freshrpms.net Release : 8.1.fc1.fr Build Date: Thu 25 Mar 2004 12:45:45 PM PST . . . Blackbox is a window manager for the X Window environment, which is...
In the previous example, the long command line shown on three lines should actually be typed on one line. If you are concerned about the content or legality of downloading a package, this example is a way to read the description of a package before you even download it.
In the following example, the command lists the files contained in a package that is in the current directory:
# rpm -qp -l RealPlayer-8.0-1.i386.rpm
Again, this is an excellent way to find out what is in a package before you install it.
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.
The verify option uses the uppercase letter (-V), while the verbose option uses the lowercase (-v).
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.
A utility is available to browse the contents of RPM files from Microsoft 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).
If no binary version of the package that you want is available, or if you just want to tailor a package to your needs, you can always install the package from source code. The SRPMS directory on the DVD that comes with this book contains the source code equivalent (SRPMs) of the binary packages you installed. You can modify the source code and rebuild it to suit your needs.
Software packages that are not available in RPM format are typically available in the form of a tarball (a bunch of files grouped together into a single file formatted by the tar utility) that has been compressed (typically by the gzip utility). Although the exact instructions for installing an application from a source code archive vary, many packages that are in the .tgz, .gz and .tar formats follow the same basic procedure.
Before you install from source code, you will need to install a variety of software development packages. If you have the disk space, I recommend that you install all software development packages that are recommended during Fedora Core installation.
The following is a minimal list of C-programming software development tools:
gcc — Contains the gcc (GNU C compiler) compiler.
make — Contains the make command for making the binaries from Makefiles.
glibc — Contains important shared libraries, the C library, and the standard math library.
glibc-devel — Contains standard header files needed to create executables.
binutils — Contains utilities needed to compile programs (such as the assembler and linker).
kernel-source — Contains the Linux kernel source code and is needed to rebuild the kernel.
libc — Contains libraries needed for programs that were based on libc 5, so older applications can run on glibc (libc 6) systems.
To install a source package from the Fedora Core source directory, do the following:
Insert the Fedora Core source DVD into the DVD drive. It should mount automatically. (If it doesn't, type mount /media/cdrw_dvdrom in a Terminal window as root.)
Change to the source directory on the DVD. For example:
# cd /media/cdrw_dvdrom/SRPMS
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 Fedora Core source tree (/usr/src/redhat/SOURCES). Spec files are copied to /usr/src/redhat/SPECS.
Change to the SPECS directory as follows:
# cd /usr/src/redhat/SPECS
Unpack the source code as follows:
# rpmbuild -bp packagename*.spec
The package’s source code is installed to the /usr/src/redhat/BUILD/package directory, where package is the name of the software package.
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.
Here are some generic instructions that you can use to install many Linux software packages that are in the gzip or tar format:
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).
Assuming the file is compressed using gzip, uncompress the file using the following command:
# gunzip package.tar.gz
The result is that the package is uncompressed and the .gz is removed from the package name (for example, package.tar).
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. (using tar xvfz package.tar.gz you can do steps 2 and 3 in one step.)
Change directories to the new subdirectory created in Step 3, as follows:
# cd package
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/local # 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 might have 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.
Even if you are not a programmer, reading the source code used to make a program can often give you insight into how that program works. Sometimes notes may be in the source code, but never make it into the documentation.
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/src/which. I then ran the gunzip and tar commands, using whichman-2.2.tar.gz and whichman-2.2.tar as arguments, 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.