In SUSE LINUX, RPM (Red Hat Package Manager) is used for managing the software packages. Its main programs are rpm and rpmbuild. The powerful RPM database can be queried by the users, the system administrators, and package builders for detailed information about the installed software.
Essentially, rpm has five modes: installing, uninstalling, or updating software packages; rebuilding the RPM database; querying RPM bases or individual RPM archives; integrity checking of packages; and signing packages. rpmbuild can be used to build installable packages from pristine sources.
Installable RPM archives are packed in a special binary format. These
archives consist of the program files to install and certain meta information
used during the installation by rpm to configure the
software package or stored in the RPM database for documentation purposes.
RPM archives normally have the extension .rpm
.
rpm can be used to administer LSB-compliant packages. Refer to Section A.4, “Standards and Specifications” for information about LSB.
![]() | Tip |
---|---|
For a number of packages, the components needed for software
development (libraries, headers, include files, etc.) have been put into
separate packages. These development packages are only needed if you want to
compile software yourself, for example, the most recent
GNOME packages. They can be identified by the name extension
|
SUSE LINUX RPM packages have a GnuPG signature. The key including the fingerprint is:
1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de> Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA
The command rpm --checksig apache-1.3.12.rpm can be used
to verify the signature of an RPM package to determine whether it really
originates from SUSE or from another trustworthy facility. This is
especially recommended for update packages from the Internet. The SUSE
public package signature key normally resides in
/root/.gnupg/
. The key is
additionally located in the directory
/usr/lib/rpm/gnupg/
to enable normal users to verify
the signature of RPM packages.
Normally, the installation of an RPM archive is quite simple:
rpm -i package
.rpm. With this
command, the package is installed, but only if its dependencies are fulfilled
and there are no conflicts with other packages. With an error message,
rpm requests those packages that need to be installed to
meet dependency requirements. In the background, the RPM database ensures that
no conflicts arise—a specific file can only belong to one package. By
choosing different options, you can force rpm to ignore
these defaults, but this is only for experts. Otherwise, risk compromising the
integrity of the system and possibly jeopardize the ability to update the
system.
The options -U
or --upgrade
and
-F
or --freshen
can be used to update a
package, for example,
rpm -F package
.rpm.
This command removes the files of the old version and immediately
installs the new files. The difference between the two versions is that
-U
installs packages that previously did not exist in the
system, but -F
merely updates previously installed
packages. When updating, rpm updates configuration files
carefully using the following strategy:
If a configuration file was not changed by the system administrator, rpm installs the new version of the appropriate file. No action by the system administrator is required.
If a configuration file was changed by the system administrator
before the update, rpm saves the changed file with
the extension .rpmorig
or
.rpmsave
(backup file) and installs the version from
the new package, but only if the originally installed file and the newer
version are different. If this is the case, compare the backup file
(.rpmorig
or .rpmsave
) with the
newly installed file and make your changes again in the new file.
Afterwards, be sure to delete all .rpmorig
and
.rpmsave
files to avoid problems with future
updates.
.rpmnew
files appear if the configuration file
already exists and if the
noreplace
label was specified in the
.spec
file.
Following an update, .rpmsave
and
.rpmnew
files should be removed after comparing them,
so they do not obstruct future updates. The .rpmorig
extension is assigned if the file has not previously been recognized by the
RPM database.
Otherwise, .rpmsave
is used. In other words,
.rpmorig
results from updating from a foreign format to
RPM. .rpmsave
results from updating from an older RPM
to a newer RPM. .rpmnew
does not disclose any
information as to whether the system administrator has made any changes to
the configuration file. A list of these files is available in
/var/adm/rpmconfigcheck
. Some configuration files (like
/etc/httpd/httpd.conf
) are not overwritten to allow
continued operation.
The -U
switch is not just an
equivalent to uninstalling with the -e
option and
installing with the -i
option. Use -U
whenever possible.
To remove a package, enter rpm -e
package
. rpm
only deletes the package if there are no unresolved dependencies. It is
theoretically impossible to delete Tcl/Tk, for example, as long as another
application requires it. Even in this case, RPM calls for assistance from
the database. If such a deletion is—for whatever reason and under
unusual circumstances—impossible, even if no
additional dependencies exist, it may be helpful to rebuild the RPM database
using the option --rebuilddb
.
To guarantee the operational security of a system, update packages must be installed in the system from time to time. Previously, a bug in a package could only be eliminated by replacing the entire package. Large packages with bugs in small files could easily result in large amounts of data. However the SUSE RPM offers a feature enabling the installation of patches in packages.
The most important considerations are demonstrated using pine as an example:
To check this, first query the installed version of the package. For pine, this can be done with
rpm -q pine pine-4.44-188
Then check if the patch RPM is suitable for this version of pine:
rpm -qp --basedon pine-4.44-224.i586.patch.rpm pine = 4.44-188 pine = 4.44-195 pine = 4.44-207
This patch is suitable for three different versions of pine. The installed version in the example is also listed, so the patch can be installed.
The files affected by a patch can easily be seen in the patch RPM.
The rpm parameter -P
allows
selection of special patch features. Display the list of files with
the following command:
rpm -qpPl pine-4.44-224.i586.patch.rpm /etc/pine.conf /etc/pine.conf.fixed /usr/bin/pine
or, if the patch is already installed, with the following command:
rpm -qPl pine /etc/pine.conf /etc/pine.conf.fixed /usr/bin/pine
Patch RPMs are used just like normal RPMs. The only difference is that a suitable RPM must already be installed.
A list of all patches installed in the system can be displayed with the
command rpm -qPa
. If only one patch is
installed in a new system (as in this example), the list appears as follows:
rpm -qPa pine-4.44-224
If, at a later date, you want to know which package version was originally installed, this information is also available in the RPM database. For pine, this information can be displayed with the following command:
rpm -q --basedon pine pine = 4.44-188
More information, including information about the patch feature of RPM, is available in the man pages of rpm and rpmbuild.
Delta RPM packages contain the difference between an old and a new
version of an RPM package.
Applying a delta RPM on an old RPM results in the complete new
RPM. It is not necessary to have a copy of the old RPM, because a
delta RPM can also work with an
installed RPM. The delta rpm packages are even smaller in size
than the patch
RPMs, which is an advantage when transferring update packages over the
Internet. The drawback is that update operations with delta RPMs involved
consume considerably more CPU cycles than plain or patch RPMs. To
make YaST use delta RPM packages during YOU sessions, set
YOU_USE_DELTAS
to “yes” in
/etc/sysconfig/onlineupdate
.
The prepdeltarpm,
writedeltarpm, and
applydeltarpm binaries are part of the
delta RPM suite and help you create and apply delta RPM packages.
With the following commands, create a delta RPM called
new.delta.rpm
(this command assumes that
old.rpm
and new.rpm
are
present):
prepdeltarpm -s seq -i info old.rpm > old.cpio prepdeltarpm -f new.rpm > new.cpio xdelta delta -0 old.cpio new.cpio delta writedeltarpm new.rpm delta info new.delta.rpm rm old.cpio new.cpio delta
Using applydeltarpm, you can reconstruct the new RPM from the file system if the old package is already installed:
applydeltarpm new.delta.rpm new.rpm
To derive it from
the old RPM without accessing the file system, use the
-r
option:
applydeltarpm -r old.rpm new.delta.rpm new.rpm
See file:///usr/share/doc/packages/deltarpm/README for technical details.
With the -q
option, rpm initiates
queries, making it possible to inspect an RPM archive (by adding the option
-p
) and also to query the RPM database of
installed packages. Several switches are available to specify the type of
information required. See Table 4.8, “The Most Important RPM Query Options”.
Table 4.8. The Most Important RPM Query Options
| Package information |
| File list |
| Query the package that contains the file
|
| File list with status information (implies
|
| List only documentation files (implies |
| List only configuration files (implies
|
| File list with complete details (to be used with
|
| List features of the package that another package can request with
|
| Capabilities the package requires |
| Installation scripts (preinstall, postinstall, uninstall) |
For example, the command rpm -q -i wget displays the information shown in Example 4.2, “rpm -q -i wget”.
Example 4.2. rpm -q -i wget
Name : wget Relocations: (not relocatable) Version : 1.9.1 Vendor: SUSE LINUX AG, Nuernberg, Germany Release : 50 Build Date: Sat 02 Oct 2004 03:49:13 AM CEST Install date: Mon 11 Oct 2004 10:24:56 AM CEST Build Host: f53.suse.de Group : Productivity/Networking/Web/Utilities Source RPM: wget-1.9.1-50.src.rpm Size : 1637514 License: GPL Signature : DSA/SHA1, Sat 02 Oct 2004 03:59:56 AM CEST, Key ID a84edae89c800aca Packager : http://www.suse.de/feedback URL : http://wget.sunsite.dk/ Summary : A tool for mirroring FTP and HTTP servers Description : Wget enables you to retrieve WWW documents or FTP files from a server. This can be done in script files or via the command line. [...]
The option -f
only works if you specify the
complete filename with its full path. Provide as many filenames as
desired. For example, the following command
rpm -q -f /bin/rpm /usr/bin/wget
results in:
rpm-4.1.1-191 wget-1.9.1-50
If only part of the filename is known, use a shell script as shown in Example 4.3, “Script to Search for Packages”. Pass the partial filename to the script shown as a parameter when running it.
Example 4.3. Script to Search for Packages
#! /bin/sh for i in $(rpm -q -a -l | grep $1); do echo "\"$i\" is in package:" rpm -q -f $i echo "" done
The command rpm -q --changelog rpm displays a detailed
list of information (updates, configuration, modifications, etc.) about a
specific package. This example shows information about the package
rpm
. However, only the last five
change entries in the RPM database are listed. All entries (dating back the
last two years) are included in the package itself. This query only works if
CD 1 is mounted at /media/cdrom
:
rpm -qp --changelog /media/cdrom/suse/i586/rpm-4*.rpm
With the help of the installed RPM database, verification checks can be
made. Initiate these with -V
,
-y
, or --verify
. With this option,
rpm shows all files in a package that have been
changed since installation. rpm uses eight character
symbols to give some hints about the following changes:
Table 4.9. RPM Verify Options
| MD5 check sum |
| File size |
| Symbolic link |
| Modification time |
| Major and minor device numbers |
| Owner |
| Group |
| Mode (permissions and file type) |
In the case of configuration files, the letter c
is
printed. For example, for changes to /etc/wgetrc
(wget
):
rpm -V wget S.5....T c /etc/wgetrc
The files of the RPM database are placed in
/var/lib/rpm
. If the partition /usr
has a size of 1 GB, this database
can occupy nearly 30 MB, especially after a complete update. If the
database is much larger than expected, it is useful to rebuild the database
with the option --rebuilddb
. Before doing this, make a
backup of the old database. The cron script
cron.daily makes daily copies of the database (packed
with gzip) and stores them in /var/adm/backup/rpmdb
.
The number of copies is controlled by the variable
MAX_RPMDB_BACKUPS
(default: 5
) in
/etc/sysconfig/backup
. The size of a single backup is
approximately 3 MB for 1 GB in
/usr
.
All source packages of SUSE LINUX carry a
.src.rpm
extension (source RPM).
![]() | Tip |
---|---|
Source packages can be copied from the installation medium to the hard disk
and unpacked with YaST. They are not, however, marked as installed
( |
The following directories must be available for rpm
and rpmbuild in /usr/src/packages
(unless you specified custom settings in a file like
/etc/rpmrc
):
SOURCES
for the original sources (.tar.bz2
or
.tar.gz
files, etc.) and for distribution-specific
adjustments (mostly .diff
or .patch
files)
SPECS
for the .spec files, similar to a meta Makefile, which control the build process
BUILD
all the sources are unpacked, patched, and compiled in this directory
RPMS
where the completed binary packages are stored
SRPMS
here are the source RPMs
When you install a source package with YaST, all the necessary components
are installed in /usr/src/packages
: the sources and the
adjustments in SOURCES
and the
relevant .spec
file in SPECS
.
![]() | Warning |
---|---|
Do not experiment with system components ( |
The following example uses the wget.src.rpm
package. After installing the package with YaST, you should have
files similar to the following listing:
/usr/src/packages/SOURCES/nops_doc.diff /usr/src/packages/SOURCES/toplev_destdir.diff /usr/src/packages/SOURCES/wget-1.9.1+ipvmisc.patch /usr/src/packages/SOURCES/wget-1.9.1-brokentime.patch /usr/src/packages/SOURCES/wget-1.9.1-passive_ftp.diff /usr/src/packages/SOURCES/wget-LFS-20040909.tar.bz2 /usr/src/packages/SOURCES/wget-wrong_charset.patch /usr/src/packages/SPECS/wget.spec
rpmbuild -b X
/usr/src/packages/SPECS/wget.spec starts the compilation.
X
is a wild card for various stages of the build
process (see the output of --help
or the RPM documentation
for details). The following is merely a brief explanation:
-bp
Prepare sources in /usr/src/packages/BUILD
:
unpack and patch.
-bc
Do the same as -bp
, but with additional
compilation.
-bi
Do the same as -bp
, but with additional
installation of the built software. Caution: if the package does not
support the BuildRoot feature, you might overwrite configuration
files.
-bb
Do the same as -bi
, but with the additional
creation of the binary package. If the compile was successful, the binary
should be in /usr/src/packages/RPMS
.
-ba
Do the same as -bb
, but with the additional
creation of the source RPM. If the compilation was successful, the binary
should be in /usr/src/packages/SRPMS
.
--short-circuit
Skip some steps.
The binary RPM created can now be installed with rpm
-i
or, preferably, with rpm
-U
. Installation with rpm makes
it appear in the RPM database.
The danger with many packages is that unwanted files are added to the
running system during the build process. To prevent this, use
build
, which creates a defined environment in which
the package is built. To establish this chroot environment, the
build script must be provided with a complete package tree.
This tree can be made available on the hard disk, via NFS, or from DVD. The
respective position is specified with build --rpms
directory
. Unlike rpm,
the build command looks for the SPEC file in the source
directory. To build wget (like in the above example) with the DVD mounted
in the system under /media/dvd
, use the following commands
as root
:
cd /usr/src/packages/SOURCES/ mv ../SPECS/wget.spec . build --rpms /media/dvd/suse/ wget.spec
Subsequently, a minimum environment is established at
/var/tmp/build-root
. The package is built in this
environment. Upon completion, the resulting packages are located in
/var/tmp/build-root/usr/src/packages/RPMS
.
The build script offers a number of additional
options. For example, cause the script to prefer your own RPMs, omit
the initialization of the build environment, or limit the
rpm command to one of the above-mentioned stages.
Access additional information with build
--help
and by reading the
build man page.
Midnight Commander (mc) can
display the contents of RPM archives and copy parts of them. It represents
archives as virtual file systems, offering all usual menu options of
Midnight Commander. Display the HEADER
with
F3. View the archive structure with
the cursor keys and Enter. Copy archive components
with F5.
KDE offers the kpackage tool as a front-end for rpm. A full-featured package manager is available as a YaST module (see Section 2.2.1, “Installing and Removing Software”).