NORDUGRID-MEMO-4

RPM for Everybody

You've been told that working with RPMs needs system administrator privileges? You've been misled.

Contents

  1. Listing Contents of an RPM Package
  2. Printing Out an RPM Package Information
  3. Simple Unpacking of an RPM Archive
  4. Creating a Private RPM Database
  5. Installing an RPM Package
  6. Upgrading RPM Packages
  7. Relocating RPM Packages
  8. Dealing with Dependencies
  9. Listing Installed Packages
  10. Uninstalling RPM Packages
  11. Building RPM from Source

RPM stands for "RedHat Package Manager" and is a sophisticated archiving format, allowing not only to pack a set of files and directories in a single archive, but also to install them in an easy-to-manage manner. While a Tape Archive (.tar) or a ZIP archive, with which you may be familiar with, simply packs files with their relative paths, RPM stores entire directory information starting from the root. RPM also relies on a system-wide database to register software version numbers, dependencies and other relevant data. Naturally, directory structures are different on different systems, and not every user has proper permissions to modify them. Also, not everybody is allowed to write into the main RPM database. Evidently, RPM format was created having system administrators in mind. Nevertheless, even if you are a regular user with no special privileges, you can make a fair use of the RPM packages, especially so if creators of such packages made them relocatable, i.e., user-friendly. Luckily, most NorduGrid packages are relocatable, including the distributed Globus ToolkitTM RPMs. Below are some quick instructions on how to work with RPM packages without having system administrator privileges.

1. Listing Contents of an RPM Package

To list files archived in an RPM package, issue an RPM query command:

rpm -qlp myfile.rpm

Here command line parameters have the following meaning:

q-perform a query
l-list files
p-use the specified package file (myfile.rpm in this example)

2. Printing Out an RPM Package Information

To retrieve general information about a given RPM package, issue the following RPM query:

rpm -qip myfile.rpm

Here command line parameters have the following meaning:

q-perform a query
i-print out package information
p-use the specified package file (myfile.rpm in this example)

This query will print out all the essential information stored by the creator of the RPM package in question. This may contain such fields as package name and version, creator's name, build date and – what's most important for users – relocations. Section 7 explains how to make use of this information.

3. Simple Unpacking of an RPM Archive

In many cases you would only need to extract files from an RPM archive, without performing complex operations with an RPM database. There is a simple way to do it:

rpm2cpio < myfile.rpm | cpio -i --make-directories

This method makes use of the generic GNU CPIO utility, which deals with copying files to and from archives. The rpm2cpio command converts from RPM to CPIO format, and the output of this conversion is redirected to the cpio command. Command line parameters for the latter have the following meaning:

i-extract contents
make-directories-create directories when necessary

As a result, all the contents of the RPM package will be extracted into the current directory, creating relative paths.

4. Creating a Private RPM Database

To achieve a higher flexibility and to get access to more RPM functionality, you may want to make a step forward and create your own RPM database. You only have to do it once, by issuing the following instructions:

mkdir $HOME/myrpmdb
rpmdb --initdb --dbpath $HOME/myrpmdb

or, for older versions of RPM:

mkdir $HOME/myrpmdb
rpm --initdb --dbpath $HOME/myrpmdb

Mentioned in this example directory $HOME/myrpmdb can of course be substituted with any other location which suits you best. The only requirement is that you must have write permissions in this location.

Having such a personal RPM database allows you to perform more complex operations with RPM packages, without resorting to simple unpacking and manual installation. To simplify your life even further, do the following:

echo '%_dbpath /home/yourname/myrpmdb' | cat >> $HOME/.rpmmacros

This will create a file .rpmmacros in your $HOME directory, and add there the line specifying the database location. In this example, /home/yourname/myrpmdb should be substituted with your RPM database path. This will instruct RPM to use always your personal database. If you don't want to use this feature (for example, if you have several databases), take care to append

--dbpath $HOME/myrpmdb

to each RPM instruction which refers to such a database (e.g., package installation or removal) .

It may be useful to copy the system-wide database into your own one. RPM does not provide any tool for database synchronization (yet?), thus you have to do it hard way:

cp /var/lib/rpm/* $HOME/myrpmdb/.

Here /var/lib/rpm/ is a typical default location of the system-wide database (it could be different though on different systems). Having thus your private database initialized with the existing system information may help you in dealing with dependencies (see Section 8), but only for a while, since any system-wide upgrades will not be registered in your database, and there is no way to synchronize RPM databases in a clever manner.

5. Installing an RPM Package

Having defined your private database (Section 4), you can attempt to install any RPM package by doing the following:

rpm -ivh myfile.rpm

Here command line parameters have the following meaning:

i-perform an installation procedure
v-print extra information
h-print progress bar with hash-marks

Keep in mind that if you didn't define a default database in $HOME/.rpmmacros, you'll have to append --dbpath $HOME/myrpmdb (or whatever is your private database location) to the directive.

Most likely, however, such a simple installation instruction will fail. There are two main reasons:

  1. RPM packages attempt to install themselves in locations defined by their creators, not by you. How to get around, read in Section 7.
  2. RPM checks for other software needed by the package – dependencies – in your private database; however, most likely, such software was not installed by you and can not be found in your database. How to deal with it, read in Section 8.

6. Upgrading RPM Packages

If you happened to have a package installed and simply want to upgrade it, issue the following instruction:

rpm -Uvh myfile.rpm

Here command line parameters have the following meaning:

U-upgrade the installation
v-print extra information
h-print progress bar with hash-marks

Since this operation needs to access a database, you either have to have the default database location specified in the $HOME/.rpmmacros file, or to append --dbpath $HOME/myrpmdb (or whatever is your private database location) to the directive (see Section 4 for details).

7. Relocating RPM Packages

As it was mentioned in Section 2, an RPM package may contain information on relocatable directories. Such directories are listed as relocations, meaning that their contents can be relocated during the installation in another directory. To perform such an installation, do the following:

rpm -ivh myfile.rpm --relocate /oldlocation=/newlocation

Here /oldlocation is one of the relocatable directories of the original package as listed by the rpm -qip myfile.rpm command, and /newlocation is your preferred destination, specified as an absolute path (starting with "/"). The command line parameters have the following meaning:

i-perform an installation procedure
v-print extra information
h-print progress bar with hash-marks
relocate-instruct RPM to install files from /oldlocation into /newlocation

As of RPM version 4.0.4, multiple relocations are possible. To use this option, specify several relocation pairs on the command line, i.e.,

--relocate /old=/new --relocate /old/subdir=/new/subdir

Order of such pairs in the line is important, as RPM will attempt to create new directories and, quite naturally, can not skip a level.

If the package information (as listed by rpm -qip) contains several relocations, you must specify a --relocate pair for all of them.

As in the case of installation, you either have to have the default database location specified in the $HOME/.rpmmacros file, or to append --dbpath $HOME/myrpmdb (or whatever is your private database location) to the directive (see Section 4 for details).

8. Dealing with Dependencies

Even when relocations proceeded smoothly, your package may still fail to get installed due to unsatisfied dependencies (this is the name for any other software needed by the package), which are absent from your private database (Section 4). A bold way to deal with it is to force the installation, e.g.:

rpm -ivh myfile.rpm --relocate /oldlocation=/newlocation --nodeps

The command line parameters have the following meaning:

i-perform an installation procedure
v-print extra information
h-print progress bar with hash-marks
relocate-instruct RPM to install files from /oldlocation into /newlocation
nodeps-ignore dependencies

This is an admittedly non-elegant way. A better solution may be to enter the necessary information into the database by installing "virtual" RPMs which only register a database record without actually installing software; however this is clearly package-dependent, thus you should request such a "fake" RPM from the package provider. An example of a shell script building such a virtual RPM can be found here.

9. Listing Installed Packages

To list all the packages installed via RPM mechanisms, do:

rpm -qai

Here command line parameters have the following meaning:

q-perform a query
a-query all installed packages
i-print out package information

This command prints out the information stored in your RPM database, hence you either have to have the default database location specified in the $HOME/.rpmmacros file, or to append --dbpath $HOME/myrpmdb (or whatever is your private database location) to the directive (see Section 4 for details).

10. Uninstalling RPM Packages

Whenever you'll have to uninstall a package, issue the instruction:

rpm -e mypackage

Here mypackage is the name of the package as listed by the rpm -qai command. Command line parameter has the following meaning:

e-uninstall packages

This command removes the files associated with the package from your system and erases the corresponding record from your RPM database. You either have to have the default database location specified in the $HOME/.rpmmacros file, or to append --dbpath $HOME/myrpmdb (or whatever is your private database location) to the directive (see Section 4 for details).

11. Building RPM from Source

It may happen so that binary RPM packages for your system are unavailable, but a source RPM or a tarball is provided. You can build a binary RPM yourself from such sources, but some extra manipulations should be made first.

The default RPM top directory is /usr/src/redhat (for a RedHat system). Naturally, as a user, you have no write permission there. To solve the problem, start by creating a new directory structure in any place which has enough disk space and write permission:

mkdir -p rpmtop/RPMS/i386; mkdir rpmtop/SRPMS; mkdir rpmtop/SOURCES; mkdir rpmtop/BUILD; mkdir rpmtop/SPECS

Now you should instruct RPM to use this directory instead of the system-wide one (assuming you created the rpmtop structure in /home/yourname/):

echo '%_topdir /home/yourname/rpmtop' | cat >> $HOME/.rpmmacros

Next thing you should take care of, is the temporary directory for RPM builds, which by default is /var/tmp, also unavailable for users. The solution is similar to the above, to create your own directory in any place which has enough disk space and write permission:

mkdir mytmp

This directory should also be specified in your .rpmmacros file:

echo '%_tmppath /home/yourname/mytmp' | cat >> $HOME/.rpmmacros

That's it; from now on you should be able to build binary RPMs from source by using the command:

rpmbuild --rebuild mypackage.src.rpm

Here mypackage.src.rpm is a source RPM. If a source is provided as a tarball, e.g., mypackage.tar.gz, use

rpmbuild -ta mypackage.tar.gz

Your RPMs will be placed in /home/yourname/rpmtop/RPMS/i386/ directory of the example above. In case your architecture is different from i386, please take care of creating a corresponding subdirectory in rpmtop/RPMS (e.g., rpmtop/RPMS/alpha).

O.Smirnova
NorduGrid homepage