Open Source

Take advantage of the full power of RPM for installing Linux software

Get an explanation of the power of RPM and learn how to use the various options for installing, upgrading, and removing software.

According to one of our latest TechProGuild polls, one of the most difficult aspects of using and managing Linux is application installation. The Red Hat Package Management (rpm) system could be changing those findings. This application seems to have it all, including that apparently important ease-of-use quality.

In this Daily Drill Down, I am going to explain exactly how simple it is to install applications with the rpm system in the Linux environment. In the process, I’ll also discuss how to upgrade, remove, and query Linux applications with the rpm tool.

The difference
Unlike the Microsoft environment, Linux allows you to undertake application installation in various ways. The most popular installation methods are via source and rpm files.

Installing via rpm is a far cry from installing with source. Installing with rpm files is like a typical installation under Windows—you point and you click (when using a package management application). Installing via source code, on the other hand, doesn’t really have a Windows equivalent unless you have used one of the Integrated Development Environments (IDEs) such as Microsoft Visual C++ Studio or Visual SlickEdit. In these cases, installing via source code would be like opening up a project, compiling that project, and building that project.

Why use rpm?
The main advantage to installing with the rpm system (rpms) is that it is amazingly simple. Whether you use the rpms through one of the package management tools (such as GnoRPM, Kpackage, or Ximian Red-Carpet) or via command line, rpm files offer the simplest application installation available for Linux. The rpm file is also prebuilt on various machines and distributions. This means that if you were installing, for example, firestarter on a Red Hat 7.2 machine, you would simply get the rpm file based on that machine. When you install the rpm file created for your technology, the file is more than likely going to install without a problem. (There are exceptions, of course.)

Along those same lines, rpm packages typically install applications so that they are globally recognized. This means that if you install an application via source and you install it into /usr/local/, another application may not be aware of this application’s existence. For example, if you install your java application via rpms, the programs that normally depend on that environment will know where that implementation of java resides. When installing via source, this may not be the case. This is because rpm files generally install in standard directories (user executable binaries in /usr/bin, root executable binaries in /usr/sbin, and so on). This can make a huge difference down the road when you are installing applications that depend on previously installed apps.

This brings me to my next advantage: When installing via rpms, the installation is logged to a database that rpm uses to keep track of what is installed, when it was installed, and what dependencies that package meets or needs.

One other very handy advantage of rpm is how cleanly the packages are uninstalled. Even more powerful than Microsoft’s ability to uninstall a package is rpm’s ability to remove every trace of an application (with the exception of user-created directories and files), and it does so without destroying other packages.

Rpm also boasts heightened security. By using the rpm system, you are writing to a database that keeps a close record of detailed information on your packages. If something seems suspicious, you can just compare it to the database. This makes for a very handy troubleshooting tool when dealing with hackers.

The disadvantages to installing via rpms are clear-cut. The primary drawback is that you are not gaining the benefit of building an application specific to your machine. The rpm you are installing is based on the hardware that the package maintainer used and may not be optimized for your machine.

The other disadvantage is that you have less control over the environment the package creates. Should your Linux machine have certain user-defined quirks (such as a particular package being installed in a nonstandard location), you can’t tell rpm to install that package in a different location or even tell rpm where the nonstandard location is.

Installing with rpm
I’m going to first look at installing rpm packages via the command line. The command and its arguments are used to do the following tasks to packages: query, verify, install, uninstall, upgrade, and build. The rpm application can also act upon its own database with the creating and rebuilding tasks.

The rpm command has some arguments that are global (meaning that they can be used for installing, querying, upgrading, and uninstalling). Some of these arguments are preceded by a single dash (-), some are preceded by a double dash (—), and all are shown in Table 1.

Table 1
Argument Description
-v Prints verbose information as package is installed
-vv Prints debugging information as package is installed
—version Prints which version of rpm is being used
—help Prints a long usage message
—quiet Prints as little information as possible


The basic installation command looks like:
rpm -i {install options} PACKAGE_FILE

The installation of packages must be done under the root user. So anytime a package is to be installed, you have to su to root (with the command su, which will then ask you for root's password) and then issue the installation command. When installing with rpm, you have a few options you can add to the command. Table 2 shows a partial listing of the install options. (To get the complete listing, run man rpm from the command prompt.) Each of the below options must be preceded by a double dash (—).

Table 2
Argument Description
allfiles Installs or upgrades all the missing files in the package, regardless of if they exist
excludedocs Doesn't install documentation
h Prints out hash marks (#) to indicate installation progress
justdb Updates only the database, not the file system
nodeps Does not do a dependency check before installing
oldpakage Allows a “downgrade” of a package
percent Prints percentage as package is installed
nobuild Does not actually install the package; just checks for potential problems

Now it’s time to put this all together. Say you want to install a new application on your system. I'll call this application linux_app-1.0.1.i386.rpm. To just do the basic install, you will su to root and run the command:
rpm -i linux_app-1.0.1.i386.rpm

The above command will install the application (if there are not any dependency errors), but it won’t print out any information. Since most administrators (and Linux users in general) like to get some information back, the command:
rpm -ivh linux_app-1.0.1.i386.rpm

is preferred.

The above command can be taken one step further by adding debugging information. To do this, run the command:
rpm -ivvh linux_app-1.0.1.i386.rpm

Of course, when running with the debug option, the information passes by so quickly that it's almost useless. Trying to echo the output to a file does no good because it will only pick up the hash marks left behind by the -v argument. It is best, when running the -vv argument, that you make sure your console window does NOT have the scroll bar hidden (so that you can scroll through the complete text).

One of the nice things about installing via rpm is that the package does not have to be on the local machine. This makes system administration much easier. (Packages can be located on a central server instead of each machine.) In order to install a package that is not local to that machine, you would simply run the command as normal—with one exception. The exception is that the PACKAGE_NAME will begin with the IP address (or URL) of the location of the package. Let's say you want to install linux_app-1.0.1.i386.rpm on a client machine on your internal LAN. The server housing all of your Linux rpm files is The files are located in the Web server’s document root (i.e., /var/www/html/) in a directory called apps, so they can be accessed via http. With this information, you would run:
rpm -ivh

After issuing this command, the installation would go off as if the rpm file was located on the local machine.

One aspect of installing with rpm that can be handy—but should be avoided as often as possible—is using the —nodeps argument. This argument installs the application without doing a dependency check first. This can easily (and often) install an application that will not work because the dependencies (the other applications the newly installed app depend on) are not there. There will be occasions when you know a particular application is not installed, but you don’t need that functionality with the new application. Java is a good example of this. You may be installing a new app that requires Java to be installed for a particular function to work. Since you won’t need that particular function, you can install without doing a dependency check. To do this, you would issue:
rpm -ivh —nodeps linux_app-1.0.1.i386.rpm

Just remember to use this argument with caution.

Upgrading with rpm
The upgrade process with rpm is as simple as the installation process. The options for upgrading are the same as they are with installation—with one exception: The main argument is -U (for upgrading) as opposed to -i (for installing).

So if you want to upgrade the current linux_app package on a machine to the newest version (my 1.0.1), you would run:
rpm -Uvh linux_app-1.0.1.i386.rpm

Other than upgrading a package, the only other difference is that the -U argument removes all older packages (of the ones just upgraded) upon completing the upgrade process.

Erasing with rpm
When you need to remove (uninstall) a package from your system, you will use the -e (erase) switch. Along with this switch, you have a few arguments from which to choose. Table 3 shows you the most useful arguments:

Table 3
Argument Description
—allmatches Erases all versions of a PACKAGE installed
—nodeps Does not do a dependency check before erasing
—repackage Puts the files back together after they are uninstalled

As with the installation, using —nodeps can be dangerous because it can break other packages that are dependent on the package being erased. Use this with caution. The —repackage option is handy because it will put the installed package back together. So if you are erasing linux_app and you use the —repackage option, the file linux_app-1.0.1.i386.rpm will be put back together. Because of this, you don’t necessarily have to keep all those rpm files lying around on your hard drive.

Querying with rpm
Where the rpm package really shines is queries. Querying with rpm takes on the following syntax:
rpm {-q|—query} [select-options] [query-options]

The query options are actually far more complex than either the install or upgrade commands. Here you will interact with either a given package or the rpm database for information.

The first thing you might want to do is check to see if a package is installed. Let's say you're not sure if linux_appis installed on a particular machine. With rpm, you can issue the commandrpm -q linux_appto find out. If the app is installed, using rpm with the -qswitch will tell you what version of the app is installed. If you want more information than was reported with just-q,you can add the -iargument, which will add the name, version, and description of the installed application. If you want to know the individual packages that make up a single application, you can add the -largument (as inrpm -qil linux_app), which will add a list of the individual packages making uplinux_app.

Other useful query arguments are listed in Table 4.

Table 4
Argument Description
—last Displays the date when the package was last installed or upgraded
—provides Lists the capabilities this package provides
-p Queries an uninstalled package
-V Verifies a package

The -V (verify) argument, above, is handy for checking a package’s integrity, which can be helpful with security measures. For example, say out of nowhere bash begins acting strangely. (Anytime you attempt to open a bash prompt, it immediately opens to /tmp instead of your home directory.) This could be a possible sign of a hacker. To check to see if bash has been tampered with, you can verify the application with:
rpm -V bash

If there are problems with bash, they will be reported in the form of an eight-character string. The string consists of the following possibilities:
  • S denotes a change in file size.
  • M denotes a difference in permissions and type.
  • 5 denotes a difference in the MD5 value.
  • D denotes a device major/minor number mismatch.
  • L denotes a difference in a symbolic link path.
  • U denotes a difference in user ownership.
  • G denotes a difference in group ownership.
  • T denotes a difference in modification time.

So let's say you do a verification on bash and you get returned something like S.5....T. That output would inform you that the file size is different than that in the database, the MD5 differs from the database, and the modification time differs from the database. Now this could be just a problem with an installation, but when you're dealing with something as crucial as bash, it would be safest to assume that something larger is amiss.

There is no question that the Red Hat Package Management system is powerful, plain, and simple. With the ability to install, uninstall, query, repair, and report, this tool goes far beyond what other installation utilities can only dream of doing.

So the next time you have to install an application on Linux, make sure you look into snagging the rpm version—and install with power.

About Jack Wallen

Jack Wallen is an award-winning writer for TechRepublic and He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website

Editor's Picks

Free Newsletters, In your Inbox