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

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:

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.

	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.

zypper source-install package_name
   

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

zypper search -t srcpackage

zypper verify

zypper install-new-recommends

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 15.1, “Upgrading the System”.

zypper patch

zypper patch --bugzilla=number

zypper patch --cve=number 

zypper patch --cve=CVE-2010-2713

zypper update

zypper update package_name
zypper install package_name

zypper list-updates

zypper list-updates --all

8.1.3.3. Upgrading to a New Product Version¶

To easily upgrade your installation to a new product version (for example, from openSUSE 11.2 to openSUSE 11.3), first adjust your repositories to match the current openSUSE repositories. For details, refer to Section 8.1.4, “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 15.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.

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.

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:

# | Alias                 | Name                  | Enabled | Refresh
--+-----------------------+-----------------------+---------+--------
1 | Updates               | Updates               | Yes     | Yes
2 | openSUSE 11.2-0       | openSUSE 11.2-0       | No      | No
3 | openSUSE-11.2-Debug   | openSUSE-11.2-Debug   | No      | Yes
4 | openSUSE-11.2-Non-Oss | openSUSE-11.2-Non-Oss | Yes     | Yes
5 | openSUSE-11.2-Oss     | openSUSE-11.2-Oss     | Yes     | Yes
6 | openSUSE-11.2-Source  | openSUSE-11.2-Source  | No      | Yes

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 as the URI or the priority of the repository are not displayed. Use the following command to list all details:

zypper repos -d

zypper addrepo URI alias

zypper removerepo 3

zypper modifyrepo -er -p 20 'updates'

zypper renamerepo 'Mozilla Firefox' firefox

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

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.

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.

For more information on managing software from the command line, enter zypper help, zypper help command or refer to the zypper(8) manpage. For a complete and detailed command reference, including cheat sheets with the most important commands, and information on how to use Zypper in scripts and applications, refer to http://en.opensuse.org/SDB:Zypper_usage. A list of software changes for the latest openSUSE version can be found at . .

RPM packages have a GnuPG 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.

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:

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.

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:

More information, including information about the patch feature of RPM, is available in the man pages of rpm and rpmbuild.

	Official Updates for openSUSE
In order to make the download size of updates as small as possible, official updates for openSUSE are not provided as Patch RPMs, but as Delta RPM packages. For details, see Section 8.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 prepdeltarpm, writedeltarpm and applydeltarpm binaries are part of the delta RPM suite (package deltarpm) and help you create and apply delta RPM packages. With the following commands, create a delta RPM called new.delta.rpm. The following 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

Finally, remove the temporary working files old.cpio, new.cpio, and 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 /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 8.1, “The Most Important RPM Query Options”.

For example, the command rpm -q -i wget displays the information shown in Example 8.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 8.3, “Script to Search for Packages”. Pass the partial filename to the script shown as a parameter when running it.

#! /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 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:

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.

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

	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):

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.

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 -bX /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:

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

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 4, Installing or Removing Software.