Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 11 SP4

6 Managing Software with Command Line Tools

This chapter describes Zypper and RPM, two command line tools for managing software. For a definition of the terminology used in this context (for example, repository, patch, or update) refer to Section 9.1, “Definition of Terms”.

6.1 Using Zypper

Zypper is a command line package manager for installing, updating and removing packages as well as for managing repositories. Zypper's syntax is similar to that of rug. In contrast to rug, Zypper does not require the zmd daemon to run behind the scenes. For more information about rug compatibility, see man zypper, section COMPATIBILITY WITH RUG. It is especially useful for accomplishing remote software management tasks or managing software from shell scripts.

6.1.1 General Usage

The general syntax of Zypper is:

zypper [global-options]command[command-options][arguments] ...

The components enclosed in brackets are not required. The simplest way to execute Zypper is to type its name, followed by a command. For example, to apply all needed patches to the system type:

zypper patch

Additionally, you can choose from one or more global options by typing them just before the command. For example, --non-interactive means running the command without asking anything (automatically applying the default answers):

zypper --non-interactive patch

To use the options specific to a particular command, type them right after the command. For example, --auto-agree-with-licenses means applying all needed patches to the system without asking to confirm any licenses (they will automatically be accepted):

zypper patch --auto-agree-with-licenses

Some commands require one or more arguments. When using the install command, for example, you need to specify which package(s) to install:

zypper install mplayer

Some options also require an argument. The following command will list all known patterns:

zypper search -t pattern

You can combine all of the above. For example, the following command will install the mplayer and amarok packages from the factory repository while being verbose:

zypper -v install --from factory mplayer amarok

The --from option makes sure to keep all repositories enabled (for solving any dependencies) while requesting the package from the specified repository.

Most Zypper commands have a dry-run option that does a simulation of the given command. It can be used for test purposes.

zypper remove --dry-run MozillaFirefox

Zypper supports the global --userdata string option for transaction identification purposes. The user-defined string is passed to Zypper history logs in /var/log/zypp/history and Snapper.

zypper --userdata string patch

6.1.2 Installing and Removing Software with Zypper

To install or remove packages use the following commands:

zypper install package_name
zypper remove package_name

Zypper knows various ways to address packages for the install and remove commands:

by the exact package name (and version number)
zypper install MozillaFirefox

or

zypper install MozillaFirefox-3.5.3
by repository alias and package name
zypper install mozilla:MozillaFirefox

Where mozilla is the alias of the repository from which to install.

by package name using wild cards

The following command will install all packages that have names starting with Moz. Use with care, especially when removing packages.

zypper install 'Moz*'
by capability

For example, if you would like to install a perl module without knowing the name of the package, capabilities come in handy:

zypper install 'perl(Time::ParseDate)'
by capability and/or architecture and/or version

Together with a capability you can specify an architecture (such as i586 or x86_64) and/or a version. The version must be preceded by an operator: < (lesser than), <= (lesser than or equal), = (equal), >= (greater than or equal), > (greater than).

zypper install 'firefox.x86_64'
zypper install 'firefox>=3.5.3'
zypper install 'firefox.x86_64>=3.5.3'
by path to the RPM file

You can also specify a local or remote path to a package:

zypper install /tmp/install/MozillaFirefox.rpm
zypper install http://download.opensuse.org/repositories/mozilla/SUSE_Factory/x86_64/MozillaFirefox-3.5.3-1.3.x86_64.rpm

To install and remove packages simultaneously use the +/- modifiers. To install emacs and remove vim simultaneously, use:

zypper install emacs -vim

To remove emacs and install vim simultaneously, use:

zypper remove emacs +vim

To prevent the package name starting with the - being interpreted as a command option, always use it as the second argument. If this is not possible, precede it with --:

zypper install -emacs +vim       # Wrong
zypper install vim -emacs        # Correct
zypper install -- -emacs +vim    # same as above
zypper remove emacs +vim         # same as above

If (together with a certain package) you automatically want to remove any packages that become unneeded after removing the specified package, use the --clean-deps option:

rm package_name --clean-deps

By default, Zypper asks for a confirmation before installing or removing a selected package, or when a problem occurs. You can override this behavior using the --non-interactive option. This option must be given before the actual command (install, remove, and patch) as in the following:

zypper --non-interactive install package_name

This option allows the use of Zypper in scripts and cron jobs.

Warning
Warning: Do not Remove Mandatory System Packages

Do not remove packages such as glibc, zypper, kernel, or similar packages. These packages are mandatory for the system and, if removed, may cause the system to become unstable or stop working altogether.

6.1.2.1 Installing or Downloading Source Packages

If you want to install the corresponding source package of a package, use:

zypper source-install package_name

That command will also install the build dependencies of the specified package. If you do not want this, add the switch -D. To install only the build dependencies use -d.

zypper source-install -D package_name # source package only
zypper source-install -d package_name # build dependencies only

Of course, this will only work if you have the repository with the source packages enabled in your repository list (it is added by default, but not enabled). See Section 6.1.5, “Managing Repositories with zypper” for details on repository management.

A list of all source packages available in your repositories can be obtained with:

zypper search -t srcpackage

You can also download source packages for all installed packages to a local directory. To download source packages, use:

zypper source-download

The default download directory is /var/cache/zypper/source-download. You can change it using the --directory option. To only show missing or extraneous packages without downloading or deleting anything, use the --status option. To delete extraneous source packages, use the --delete option. To disable deleting, use the --no-delete option.

6.1.2.2 Utilities

To verify whether all dependencies are still fulfilled and to repair missing dependencies, use:

zypper verify

In addition to dependencies that must be fulfilled, some packages recommend other packages. These recommended packages are only installed if actually available and installable. In case recommended packages were made available after the recommending package has been installed (by adding additional packages or hardware), use the following command:

zypper install-new-recommends

This command is very useful after plugging in a webcam or WLAN device. It will install drivers for the device and related software, if available. Drivers and related software are only installable if certain hardware dependencies are fulfilled.

6.1.3 Updating Software with Zypper

There are three different ways to update software using Zypper: by installing patches, by installing a new version of a package or by updating the entire distribution. The latter is achieved with the zypper dist-upgrade command which is discussed in Section 6.1.4, “Distribution Upgrade with zypper”.

6.1.3.1 Installing Patches

To install all officially released patches applying to your system, just run:

zypper patch

In this case, all patches available in your repositories are checked for relevance and installed, if necessary. After registering your SUSE Linux Enterprise Server installation, an official update repository containing such patches will be added to your system. The above command is all you must enter in order to apply them when needed.

Zypper knows three different commands to query for the availability of patches:

zypper patch-check

Lists the number of needed patches (patches, that apply to your system but are not yet installed)

~ # zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches

Lists all needed patches (patches, that apply to your system but are not yet installed)

~ # zypper list-patches
Loading repository data...
Reading installed packages...
 
Repository                          | Name      | Version | Category | Status
------------------------------------+-----------+---------+----------+-------
Updates for openSUSE 11.3 11.3-1.82 | lxsession | 2776    | security | needed
zypper patches

Lists all patches available for SUSE Linux Enterprise Server, regardless of whether they are already installed or apply to your installation.

It is also possible to list and install patches relevant to specific issues. To list specific patches, use the zypper list-patches command with the following options:

--bugzilla[=number]

Lists all needed patches for Bugzilla issues. Optionally, you can specify a bug number if you only want to list patches for this specific bug.

--cve[=number]

Lists all needed patches for CVE (Common Vulnerabilities and Exposures) issues, or only patches matching a certain CVE number, if specified. By default, only unapplied patches are listed. Use -a to list all.

To install a patch for a specific Bugzilla or CVE issue, use the following commands:

zypper patch --bugzilla=number

or

zypper patch --cve=number

For example, to install a security patch with the CVE number CVE-2010-2713, execute:

zypper patch --cve=CVE-2010-2713

6.1.3.2 Installing Updates

If a repository contains only new packages, but does not provide patches, zypper patch does not show any effect. To update all installed packages with newer available versions, use:

zypper update

To update individual packages, specify the package with either the update or install command:

zypper update package_name
zypper install package_name

A list of all new installable packages can be obtained with the command:

zypper list-updates

Note that this command only packages lists packages that match the following criteria:

  • has the same vendor like the already installed package,

  • is provided by repositories with at least the same priority than the already installed package,

  • is installable (all dependencies are satisfied).

A list of all new available packages (regardless whether installable or not) can be obtained with:

zypper list-updates --all

To find out why a new package cannot be installed, just use the zypper install or zypper update command as described above.

6.1.3.3 Upgrading to a New Product Version

To easily upgrade your installation to a new product version (for example, from SUSE Linux Enterprise Server 11 to SUSE Linux Enterprise Server 11 SP1, first adjust your repositories to match the current SUSE Linux Enterprise Server repositories. For details, refer to Section 6.1.5, “Managing Repositories with zypper”. Then use the zypper dist-upgrade command with the required repositories. This command ensures that all packages will be installed from the repositories currently enabled. For detailed instructions, refer to Section 6.1.4, “Distribution Upgrade with zypper”.

To restrict the distribution upgrade to packages from a certain repository while considering also the other repositories for satisfying dependencies, use the --from option and specify the repository by either its alias, its number or URI.

Note
Note: Differences between zypper update and zypper dist-upgrade

Choose zypper update to update packages to newer versions available for your product version while maintaining system integrity. zypper update will honor the following rules:

no vendor changes
no architecture changes
no downgrades
keep installed packages

When executing zypper dist-upgrade, all packages will be installed from the repositories currently enabled. This rule is enforced, so packages might change vendor or architecture or even might get downgraded. All packages that have unfulfilled dependencies after the upgrade will be uninstalled.

6.1.4 Distribution Upgrade with zypper

With the zypper command line utility you can upgrade to the next version of the distribution. Most importantly, you can initiate the system upgrade process from within the running system.

This feature is attractive for advanced users who want to run remote upgrades or upgrades on many similarly configured systems.

6.1.4.1 Before Starting the Upgrade with zypper

To avoid unexpected errors during the upgrade process using zypper, minimize risky constellations.

  • Close as many applications and unneeded services as possible and log out all regular users.

  • Disable third party repositories before starting the upgrade, or lower the priority of these repositories to make sure packages from the default system repositories will get preference. Enable them again after the upgrade and edit their version string to match the version number of the distribution of the upgraded now running system.

  • Make sure to have the system registered. f this is not done already, it can either be registered by using the Novell Customer Center Configuration module in YaST or by using the suse_register commandline tool. This will add update sources to the system.

Warning
Warning: Perform Upgrades from Reboot

The upgrade process has to be done completely from beginning to reboot. There is only a limited chance to revert changes. Furthermore, the server has to be connected online during the whole process.

6.1.4.2 The Upgrade Procedure

Warning
Warning: Check Your System Backup

Before actually starting the upgrade procedure, check that your system backup is up-to-date and restorable. This is especially important because you must enter many of the following steps manually.

Note
Note: Registration Key

If add-ons are installed on your system, you might need to enter your registration key in order to update the system. Be prepared to have the key available.

The program zypper supports long and short command names. For example, you can abbreviate zypper install as zypper in. In the following text, the short variants are used.

Log in as root and perform the following steps:

  1. Refresh all services and repositories:

    zypper ref -s
  2. Install any package management updates:

    zypper up -t patch

    For more information, see Chapter 1, YaST Online Update.

  3. Repeat Step 2 to install all available updates for your system.

    Sidenote: If you want o use the above command in a script for an unattended upgrade, use the command:

    zypper --non-interactive patch --auto-agree-with-licenses --with-interactive
  4. Read the migration product informations from /etc/products.d/*.prod. The installed products contain information about distribution upgrades and which migration products should be installed to perform the migration. Install them with the following commands:

    1. Extract the product information:

      zypper se -t product | grep -h -- "-migration" | cut -d\| -f2

      A sample output could be as follows:

      SUSE_SLES-SP3-migration
      sle-sdk-SP3-migration
    2. Install these migration products (example):

      zypper in -t product sle-sdk-SP3-migration SUSE_SLES-SP3-migration
    3. Register the products in order to get the corresponding update repositories:

      suse_register -d 2 -L /root/.suse_register.log
      Warning
      Warning: Enable Additional Repository for SLED Users

      Some devel packages have been moved from the SLED11-SP2 installation media to the SLED11-Extras repository. In order to avoid dependency conflicts during upgrade, enable this repository before performing the actual upgrade. Execute yast2 repositories and enable SLED11-Extras there. On SLES this extra step is not needed.

  5. Refresh services and repositores:

    zypper ref -s
  6. Check the repositories using zypper lr. If needed, disable the SP1/SP2 Pool/Core/Updates repositories manually and enable the new SP3 (SP3-Pool, SP3-Updates) repositories:

    zypper mr --disable REPOALIAS
    zypper mr --enable REPOALIAS
  7. Perform a dist upgrade by using the following command (example for SLES, adjust catalog names in case SLED is updated):

    zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates

    You can add more catalogs here if needed, for example, in case addon products are installed. Zypper will report that it will delete the migration product and update the main products. Confirm the message to continue updating the rpm packages.

  8. After the upgrade is finished, register the new products again:

    suse_register -d 2 -L /root/.suse_register.log
  9. Reboot the system:

    shutdown -r

6.1.5 Managing Repositories with zypper

All installation or patch commands of Zypper rely on a list of known repositories. To list all repositories known to the system, use the command:

zypper repos

The result will look similar to the following output:

Example 6.1: Zypper—List of Known Repositories
# | Alias                             | Name                              | Enabled | Refresh
--+-----------------------------------+-----------------------------------+---------+--------
1 | SUSE-Linux-Enterprise-Server 11-0 | SUSE-Linux-Enterprise-Server 11-0 | Yes     | No
2 | SLES-11-Updates                   | SLES 11 Online Updates            | Yes     | Yes
3 | broadcomdrv                       | Broadcom Drivers                  | Yes     | No

When specifying repositories in various commands, an alias, URI or repository number from the zypper repos command output can be used. A repository alias is a short version of the repository name for use in repository handling commands. Note that the repository numbers can change after modifying the list of repositories. The alias will never change by itself.

By default, details such as the URI or the priority of the repository are not displayed. Use the following command to list all details:

zypper repos -d

Sometimes, the list contains a large number of repositories that are not enabled, which might be confusing. To only show enabled repositories, use the following command:

zypper repos -E

6.1.5.1 Adding Repositories

Warning
Warning: Possible System Compromise When Adding Repositories with Zypper

By default, digests and signatures of packages from repositories provided by SUSE are checked to ensure their integrity and origin. This GPG check is enabled in the repository configuration file on the server that provides the repository.

When adding a repository with the zypper ar command, this configuration file is downloaded to /etc/zypp/repos.d. Zypper also informs the user about GPG Check option:

GPG check: Yes

Always make sure that the GPG check output is set to Yes. If set to No your system can possibly be compromised by, for example, package downgrades that re-introduce previously fixed vulnerabilities. It is recommended not to trust repositories where this option is set to No. In case you are sure that the GPG check was disabled by mistake, re-enable the option by adding the following line to the respective repository configuration file in /etc/zypp/repos.d:

gpgcheck=1

To add a repository, run

zypper addrepo URIalias

URI can either be an Internet repository, a network resource, a directory or a CD or DVD (see http://en.opensuse.org/openSUSE:Libzypp_URIs for details). The alias is a shorthand and unique identifier of the repository. You can freely choose it, with the only exception that is has to be unique. Zypper will issue a warning if you specify an alias that is already in use.

6.1.5.2 Removing Repositories

If you want to remove a repository from the list, use the command zypper removerepo together with the alias or number of the repository you want to delete. For example, to remove the repository listed as third entry in Example 6.1, “Zypper—List of Known Repositories”, use the following command:

zypper removerepo 3

6.1.5.3 Modifying Repositories

Enable or disable repositories with zypper modifyrepo. You can also alter the repository's properties (such as refreshing behavior, name or priority) with this command. The following command will enable the repository named updates, turn on auto-refresh and set its priority to 20:

zypper modifyrepo -er -p 20 'updates'

Modifying repositories is not limited to a single repository—you can also operate on groups:

-a: all repositories
-l: local repositories
-t: remote repositories
-m TYPE: repositories of a certain type (where TYPE can be one of the following: http, https, ftp, cd, dvd, dir, file, cifs, smb, nfs, hd, iso)

To rename a repository alias, use the renamerepo command. The following example changes the alias from Mozilla Firefox to just firefox:

zypper renamerepo 'Mozilla Firefox' firefox

6.1.6 Querying Repositories and Packages with Zypper

Zypper offers various methods to query repositories or packages. To get lists of all products, patterns, packages or patches available, use the following commands:

zypper products
zypper patterns
zypper packages
zypper patches

To query all repositories for certain packages, use search. It works on package names, or, optionally, on package summaries and descriptions. Using the wild cards * and ? with the search term is allowed. By default, the search is not case-sensitive.

zypper search firefox       # simple search for "firefox"
zypper search "*fire*"      # using wild cards
zypper search -d fire       # also search in package descriptions and summaries
zypper search -u firefox    # only display packages not already installed

To search for packages which provide a special capability, use the command what-provides. For example, if you would like to know which package provides the perl module SVN::Core, use the following command:

zypper what-provides 'perl(SVN::Core)'

To query single packages, use info with an exact package name as an argument. It displays detailed information about a package. To also show what is required/recommended by the package, use the options --requires and --recommends:

zypper info --requires MozillaFirefox

The what-provides package is similar to rpm -q --whatprovides package, but RPM is only able to query the RPM database (that is the database of all installed packages). Zypper, on the other hand, will tell you about providers of the capability from any repository, not only those that are installed.

6.1.7 Configuring Zypper

Zypper now comes with a configuration file, allowing you to permanently change Zypper's behavior (either system-wide or user-specific). For system-wide changes, edit /etc/zypp/zypper.conf. For user-specific changes, edit ~/.zypper.conf. If ~/.zypper.conf does not yet exist, you can use /etc/zypp/zypper.conf as template: copy it to ~/.zypper.conf and adjust it to your liking. Refer to the comments in the file for help about the available options.

6.1.8 Troubleshooting

In case you have problems to access packages from configured repositories (for example, Zypper cannot find a certain package though you know that it exists in one the repositories), it can help to refresh the repositories with:

zypper refresh

If that does not help, try

zypper refresh -fdb

This forces a complete refresh and rebuild of the database, including a forced download of raw metadata.

6.1.9 Zypper Rollback Feature on btrfs File System

If the btrfs file system is used on the root partition and snapper is installed, Zypper automatically calls snapper (via script installed by snapper) when committing changes to the file system to create appropriate file system snapshots. These snapshots can be used for reverting any changes made by zypper. For more information about snapper, see man snapper.

Zypper (and YaST) currently only make snapshots of the root file system. Other subvolumes cannot be configured. This feature is not supported on the default file system.

6.2 RPM—the Package Manager

RPM (RPM Package Manager) is used for managing software packages. Its main commands are rpm and rpmbuild. The powerful RPM database can be queried by the users, 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.

Tip
Tip: Software Development Packages

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 libkde4-devel.

6.2.1 Verifying Package Authenticity

RPM packages have a GPG signature. To verify the signature of an RPM package, use the command rpm --checksig  package-1.2.3.rpm to determine whether the package originates from Novell/SUSE or from another trustworthy facility. This is especially recommended for update packages from the Internet.

6.2.2 Managing Packages: Install, Update, and Uninstall

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 if 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, you 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, which 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, impossible (even if no additional dependencies exist), it may be helpful to rebuild the RPM database using the option --rebuilddb.

6.2.3 RPM and Patches

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 this scenario. 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:

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 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.

Note
Note: Official Updates for SUSE Linux Enterprise Server

In order to make the download size of updates as small as possible, official updates for SUSE Linux Enterprise Server are not provided as Patch RPMs, but as Delta RPM packages. For details, see Section 6.2.4, “Delta RPM Packages”.

6.2.4 Delta RPM Packages

Delta RPM packages contain the difference between an old and a new version of an RPM package. Applying a delta RPM onto an old RPM results in a completely 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 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.

The makedeltarpm and applydelta binaries are part of the delta RPM suite (package deltarpm) and help you create and apply delta RPM packages. With the following commands, you can create a delta RPM called new.delta.rpm. The following command assumes that old.rpm and new.rpm are present:

makedeltarpm old.rpm new.rpm new.delta.rpm

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 /usr/share/doc/packages/deltarpm/README for technical details.

6.2.5 RPM Queries

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 6.1, “The Most Important RPM Query Options”.

Table 6.1: The Most Important RPM Query Options

-i

Package information

-l

File list

-f FILE

Query the package that contains the file 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 Example 6.2, “rpm -q -i wget”.

Example 6.2: rpm -q -i wget
Name        : wget                         Relocations: (not relocatable)
Version     : 1.11.4                            Vendor: openSUSE
Release     : 1.70                          Build Date: Sat 01 Aug 2009 09:49:48 CEST
Install Date: Thu 06 Aug 2009 14:53:24 CEST      Build Host: build18
Group       : Productivity/Networking/Web/Utilities   Source RPM: wget-1.11.4-1.70.src.rpm
Size        : 1525431                          License: GPL v3 or later
Signature   : RSA/8, Sat 01 Aug 2009 09:50:04 CEST, Key ID b88b2fd43dbdc284
Packager    : http://bugs.opensuse.org
URL         : http://www.gnu.org/software/wget/
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.8.0-4.3.x86_64
wget-1.11.4-11.18.x86_64

If only part of the filename is known, use a shell script as shown in Example 6.3, “Script to Search for Packages”. Pass the partial filename to the script shown as a parameter when running it.

The command rpm -q --changelog rpm displays a detailed list of change information about a specific package (in this case, the rpmpackage), sorted by date.

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 6.2: 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. For example, for changes to /etc/wgetrc (wget package):

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 1 MB for 1 GB in /usr.

6.2.6 Installing and Compiling Source Packages

All source packages carry a .src.rpm extension (source RPM).

Note
Note: Installed Source Packages

Source packages can be copied from the installation medium to the hard disk and unpacked with YaST. They are not, however, 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. When you install a source package, only the source code is added to the system.

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
Warning

Do not experiment with system components (glibc, rpm, sysvinit, etc.), because this endangers the stability of your system.

The following example uses the wget.src.rpm package. After installing the source package, you should have files similar to those in the following list:

/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2
/usr/src/packages/SOURCES/wgetrc.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.

6.2.7 Compiling RPM Packages with build

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. Set the position 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.

6.2.8 Tools for RPM Archives and the RPM Database

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.

A full-featured package manager is available as a YaST module. For details, see Chapter 9, Installing or Removing Software.

Print this page