| SUSE LINUX – Administration Guide Chapter 2. Updating the System and Package Management / 2.3. RPM — the Package Manager | ||||
|---|---|---|---|---|
 | 2.2. Software Changes from Version to Version | Part II. Configuration |  | |
| SUSE LINUX – Administration Guide Chapter 2. Updating the System and Package Management / 2.3. RPM — the Package Manager | ||||
|---|---|---|---|---|
| 2.2. Software Changes from Version to Version | Part II. Configuration | | |
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 checks 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 12.1.1. “Linux Standard Base (LSB)” for more information about LSB.
![[Tip]](admon/tip.png) | 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 -devel, such as the packages alsa-devel, gimp-devel, and kdelibs-devel. | |
SUSE LINUX RPM packages have a GnuPG signature:
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/. Since version 8.1, 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 will be 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.
rpm -F <package>.rpm
This command will remove the files of the old version and immediately install 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 will install 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.
![[Important]](admon/important.png) | Important |
|---|---|
Following every update, check the backup copies with the extension .rpmorig or .rpmsave, which are created by rpm. These are your old configuration files. If necessary, adopt your modifications from the backup copies to the new configuration file then delete the old files with the extension .rpmorig or .rpmsave. | |
To remove a package, enter rpm -e package. rpm will only delete 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 small bugs could easily result in large amounts of data. However, since SUSE 8.1, the SUSE RPM offers a new feature enabling the installation of patches in packages.
The most important considerations are demonstrated using pine as an example:
Is the patch RPM suitable for my system?
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.
Which files are replaced by the patch?
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
How can a patch RPM be installed in the system?
Patch RPMs are used just like normal RPMs. The only difference is that a suitable RPM must already be installed.
Which patches are already installed in the system and for which package versions?
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 appear 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 man rpm and in man rpmbuild.
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 2.2. “The Most Important RPM Query Options (-q [-p] …package)”).
Table 2.2. The Most Important RPM Query Options (-q [-p] …package)
| -i | Package information |
| -l | File list |
| -f FILE | Query a package owned by FILE (the full path must be specified with FILE) |
| -s | File list with status information (implies -l) |
| -d | List only documentation files (implies -l) |
| -c | List only configuration files (implies -l) |
| --dump | File list with complete details (to be used with -l, -c, or -d) |
| --provides | List features of the package that another package can request with --requires |
| --requires, -R | Capabilities the package requires |
| --scripts | Installation scripts (preinstall, postinstall, uninstall) |
For example, the command rpm -q -i wget displays the information shown in Output 2.2. “rpm -q -i wget”.
Example 2.2. rpm -q -i wget
Name :wget Relocations: (not relocateable) Version :1.8.2 Vendor: SuSE Linux AG, Nuernberg, Germany Release :301 Build Date: Di 23 Sep 2003 20:26:38 CEST Install date:Mi 08 Okt 2003 11:46:31 CEST Build Host: levi.suse.de Group :Productivity/Networking/Web/Utilities Source RPM :wget-1.8.2-301.src.rpm Size :1333235 License: GPL Signature :DSA/SHA1, Di 23 Sep 2003 22:13:12 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 file name with its full path. Provide as many file names as desired. For example, the following command
rpm -q -f /bin/rpm /usr/bin/wget
results in:
rpm-3.0.3-3 wget-1.5.3-55
If only part of the file name is known, use a shell script as shown in File 2.3. “Script to Search for Packages”. Pass the partial file name to the script shown as a parameter when running it.
Example 2.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-3*.rpm
With the help of the installed RPM database, verification checks can be made. These checks are initiated with the option -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 2.3. RPM Verify Options
| 5 | MD5 check sum |
| S | File size |
| L | Symbolic link |
| T | Modification time |
| D | Major and minor device numbers |
| U | Owner |
| G | Group |
| M | Mode (permissions and file type) |
In the case of configuration files, the letter c is printed. 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 installed with YaST, like any other package. They will not, however, be marked as installed ([i]) in the package manager. This is because the source packages are not entered in the RPM database. Only installed operating system software is listed in the RPM database. | |
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):
for the original sources (.tar.gz files, etc.) and for distribution-specific adjustments (.dif files)
for the .spec files, similar to a meta Makefile, which control the build process
all the sources are unpacked, patched, and compiled in this directory
where the completed binary packages are stored
here are the source RPMs
When you install a source package with YaST, all the necessary components will be installed in /usr/src/packages: the sources and the adjustments in SOURCES and the relevant .spec file in SPECS.
![[Warning]](admon/warning.png) | Warning |
|---|---|
Do not experiment with system components (glibc, rpm, sysvinit, etc.), as this endangers the operability of your system. | |
The following example uses the wget.src.rpm package. After installing the package with YaST, you should have the following files:
/usr/src/packages/SPECS/wget.spec /usr/src/packages/SOURCES/wget-1.4.5.dif /usr/src/packages/SOURCES/wget-1.4.5.tar.gz
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:
Prepare sources in /usr/src/packages/BUILD: unpack and patch.
Do the same as -bp, but with additional compilation.
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.
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.
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.
Allows skipping specific 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 <path>. Unlike rpm, the build command looks for the SPEC file in the source directory. To build wget anew (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 will be established at /var/tmp/build-root. The package will be 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 can be accessed with build --help and man build.
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: the HEADER information can be displayed with F3, the archive structure can be viewed with the cursor keys and Enter, and archive components can be copied with F5.
A front-end for rpm is also available for Emacs. KDE™ offers the kpackage tool. GNOME™ offers gnorpm.
Using the Alien (alien) Perl script, it is possible to convert or install an alien binary package. This tries to convert old TGZ archives to RPM before installing. This way, the RPM database can keep track of such a package after it has been installed. Beware: alien is still alpha software, according to its author — even if it already has a high version number.
