9 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 8.1, “Definition of terms”.
9.1 Using Zypper #
Zypper is a command line package manager for installing, updating, and removing packages. It also manages repositories. It is especially useful for accomplishing remote software management tasks or managing software from shell scripts.
9.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. See zypper
help
for a list of general options and all commands. To get help
for a specific command, type zypper help
COMMAND.
- Zypper commands
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, use:
>
sudo
zypper patch- Global options
Additionally, you can choose from one or more global options by typing them immediately before the command:
>
sudo
zypper --non-interactive patchIn the above example, the option
--non-interactive
means that the command is run without asking anything (automatically applying the default answers).- Command-specific options
To use options that are specific to a particular command, type them immediately after the command:
>
sudo
zypper patch --auto-agree-with-licensesIn the above example,
--auto-agree-with-licenses
is used to apply all needed patches to a system without you being asked to confirm any licenses. Instead, licenses will be accepted automatically.- Arguments
Some commands require one or more arguments. For example, when using the command
install
, you need to specify which package or which packages you want to install:>
sudo
zypper install mplayerSome options also require a single 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 mc and vim packages from
the factory
repository while being verbose:
>
sudo
zypper -v install --from factory mc vim
The --from
option keeps all repositories
enabled (for solving any dependencies) while requesting the package from the
specified repository. --repo
is an alias for --from
, and you may use either one.
Most Zypper commands have a dry-run
option that does a
simulation of the given command. It can be used for test purposes.
>
sudo
zypper remove --dry-run MozillaFirefox
Zypper supports the global --userdata
STRING
option. You can specify a string
with this option, which gets written to Zypper's log files and plug-ins
(such as the Btrfs plug-in). It can be used to mark and identify
transactions in log files.
>
sudo
zypper --userdata STRING patch
9.1.2 Using Zypper subcommands #
Zypper subcommands are executables that are stored in the directory
specified by the zypper_execdir
configuration option. It is
/usr/lib/zypper/commands
by default. If a subcommand
is not found there, Zypper automatically searches the rest of your $PATH
locations for it. This lets you create your own local extensions and store
them in user space.
Executing subcommands in the Zypper shell, and using global Zypper options are not supported.
List your available subcommands:
>
zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'
appstream-cache
lifecycle
migration
search-packages
Zypper subcommands available from elsewhere on your $PATH
log Zypper logfile reader
(/usr/sbin/zypper-log)
View the help screen for a subcommand:
>
zypper help appstream-cache
9.1.3 Installing and removing software with Zypper #
To install or remove packages, use the following commands:
>
sudo
zypper install PACKAGE_NAME>
sudo
zypper remove PACKAGE_NAME
Do not remove mandatory system packages like glibc , zypper , kernel . If they are removed, the system can become unstable or stop working altogether.
9.1.3.1 Selecting which packages to install or remove #
There are various ways to address packages with the commands
zypper install
and zypper remove
.
- By exact package name
>
sudo
zypper install MozillaFirefox- By exact package name and version number
>
sudo
zypper install MozillaFirefox-52.2- By repository alias and package name
>
sudo
zypper install mozilla:MozillaFirefoxWhere
mozilla
is the alias of the repository from which to install.- By package name using wild cards
You can select all packages that have names starting or ending with a certain string. Use wild cards with care, especially when removing packages. The following command will install all packages starting with “Moz”:
>
sudo
zypper install 'Moz*'Tip: Removing all-debuginfo
packagesWhen debugging a problem, you sometimes need to temporarily install a lot of
-debuginfo
packages which give you more information about running processes. After your debugging session finishes and you need to clean the environment, run the following:>
sudo
zypper remove '*-debuginfo'- By capability
For example, to install a package without knowing its name, capabilities come in handy. The following command will install the package MozillaFirefox:
>
sudo
zypper install firefox- By capability, hardware architecture, or version
Together with a capability, you can specify a hardware architecture and a version:
The name of the desired hardware architecture is appended to the capability after a full stop. For example, to specify the AMD64/Intel 64 architectures (which in Zypper is named
x86_64
), use:>
sudo
zypper install 'firefox.x86_64'Versions must be appended to the end of the string and must be preceded by an operator:
<
(lesser than),<=
(lesser than or equal),=
(equal),>=
(greater than or equal),>
(greater than).>
sudo
zypper install 'firefox>=74.2'You can also combine a hardware architecture and version requirement:
>
sudo
zypper install 'firefox.x86_64>=74.2'
- By path to the RPM file
You can also specify a local or remote path to a package:
>
sudo
zypper install /tmp/install/MozillaFirefox.rpm>
sudo
zypper install http://download.example.com/MozillaFirefox.rpm
9.1.3.2 Combining installation and removal of packages #
To install and remove packages simultaneously, use the
+/-
modifiers. To install emacs and
simultaneously remove vim , use:
>
sudo
zypper install emacs -vim
To remove emacs and simultaneously install vim , use:
>
sudo
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 --
:
>
sudo
zypper install -emacs +vim # Wrong>
sudo
zypper install vim -emacs # Correct>
sudo
zypper install -- -emacs +vim # Correct>
sudo
zypper remove emacs +vim # Correct
9.1.3.3 Cleaning up dependencies of removed packages #
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:
>
sudo
zypper rm --clean-deps PACKAGE_NAME
9.1.3.4 Using Zypper in scripts #
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 can be seen in
the following:
>
sudo
zypper--non-interactive
install PACKAGE_NAME
This option allows the use of Zypper in scripts and cron jobs.
9.1.3.5 Installing or downloading source packages #
To install the corresponding source package of a package, use:
>
zypper source-install PACKAGE_NAME
When executed as root
, the default location to install source
packages is /usr/src/packages/
and
~/rpmbuild
when run as user. These values can be
changed in your local rpm
configuration.
This command will also install the build dependencies of the specified
package. If you do not want this, add the switch -D
:
>
sudo
zypper source-install -D PACKAGE_NAME
To install only the build dependencies use -d
.
>
sudo
zypper source-install -d PACKAGE_NAME
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 9.1.6, “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.
9.1.3.6 Installing packages from disabled repositories #
Normally you can only install or refresh packages from enabled
repositories. The --plus-content
TAG
option helps you specify
repositories to be refreshed, temporarily enabled during the current Zypper
session, and disabled after it completes.
For example, to enable repositories that may provide additional
-debuginfo
or -debugsource
packages, use --plus-content debug
. You can specify this
option multiple times.
To temporarily enable such 'debug' repositories to install a specific
-debuginfo
package, use the option as follows:
>
sudo
zypper --plus-content debug \ install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"
The build-id
string is reported by
gdb
for missing debuginfo packages.
Repositories from the SUSE Linux Enterprise Server installation media are still
configured but disabled after successful installation. You can use the
--plus-content
option to install packages from the
installation media instead of the online repositories. Before calling
zypper
, ensure the media is available, for example by
inserting the DVD into the computer's drive.
9.1.3.7 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:
>
sudo
zypper install-new-recommends
This command is very useful after plugging in a Web cam or Wi-Fi 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.
9.1.4 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 zypper
dist-upgrade
. Upgrading SUSE Linux Enterprise Server is discussed in
Chapitre 1, Voies et méthodes de mise à niveau.
9.1.4.1 Installing all needed patches #
Patching SUSE Linux Enterprise is the most reliable way to install new versions of installed packages. It guarantees that all required packages with correct versions are installed and ensures that package versions considered as conflicting are omitted.
To install all officially released patches that apply to your system, run:
>
sudo
zypper patch
All patches available from repositories configured on your computer are
checked for their relevance to your installation. If they are relevant (and
not classified as optional
or
feature
), they are installed immediately.
If zypper patch
succeeds, it is guaranteed that no
vulnerable version package is installed unless you confirm the exception.
Note that the official update repository is only
available after registering your SUSE Linux Enterprise Server installation.
If a patch that is about to be installed includes changes that require a system reboot, you will be warned before.
The plain zypper patch
command does not apply patches
from third party repositories. To update also the third party repositories,
use the with-update
command option as follows:
>
sudo
zypper patch --with-update
To install also optional patches, use:
>
sudo
zypper patch --with-optional
To install all patches relating to a specific Bugzilla issue, use:
>
sudo
zypper patch --bugzilla=NUMBER
To install all patches relating to a specific CVE database entry, use:
>
sudo
zypper patch --cve=NUMBER
For example, to install a security patch with the CVE number
CVE-2010-2713
, execute:
>
sudo
zypper patch --cve=CVE-2010-2713
To install only patches which affect Zypper and the package management itself, use:
>
sudo
zypper patch --updatestack-only
Bear in mind that other command options that would also update other
repositories will be dropped if you use the
updatestack-only
command option.
9.1.4.2 Listing patches #
To find out whether patches are available, Zypper allows viewing the following information:
- Number of needed patches
To list the number of needed patches (patches that apply to your system but are not yet installed), use
patch-check
:>
zypper patch-check Loading repository data... Reading installed packages... 5 patches needed (1 security patch)This command can be combined with the
--updatestack-only
option to list only the patches which affect Zypper and the package management itself.- List of needed patches
To list all needed patches (patches that apply to your system but are not yet installed), use
zypper list-patches
.- List of all patches
To list all patches available for SUSE Linux Enterprise Server, regardless of whether they are already installed or apply to your installation, use
zypper patches
.
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:
- By Bugzilla issues
To list all needed patches that relate to Bugzilla issues, use the option
--bugzilla
.To list patches for a specific bug, you can also specify a bug number:
--bugzilla=NUMBER
. To search for patches relating to multiple Bugzilla issues, add commas between the bug numbers, for example:>
zypper list-patches --bugzilla=972197,956917- By CVE number
To list all needed patches that relate to an entry in the CVE database (Common Vulnerabilities and Exposures), use the option
--cve
.To list patches for a specific CVE database entry, you can also specify a CVE number:
--cve=NUMBER
. To search for patches relating to multiple CVE database entries, add commas between the CVE numbers, for example:>
zypper list-patches --cve=CVE-2016-2315,CVE-2016-2324- List retracted patches
In the SUSE Linux Enterprise 15 codestream, some patches are automatically retracted. Maintenance updates are carefully tested, because there is a risk that an update contains a new bug. If an update proves to contain a bug, a new update (with a higher version number) is issued to revert the buggy update, and the buggy update is blocked from being installed again. You can list retracted patches with
zypper
:>
zypper lp --all |grep retracted
SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-1965 | recommended | important | --- | retracted | Recommended update for multipath-tools SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-2689 | security | important | --- | retracted | Security update for cpio SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-3655 | security | important | reboot | retracted | Security update for the Linux KernelSee complete information on a retracted (or any) patch:
>
zypper patch-info SUSE-SLE-Product-SLES-15-2021-2689
Loading repository data... Reading installed packages... Information for patch SUSE-SLE-Product-SLES-15-2021-2689: --------------------------------------------------------- Repository : SLE-Product-SLES15-LTSS-Updates Name : SUSE-SLE-Product-SLES-15-2021-2689 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : retracted Category : security Severity : important Created On : Mon 16 Aug 2021 03:44:00 AM PDT Interactive : --- Summary : Security update for cpio Description : This update for cpio fixes the following issues: It was possible to trigger Remote code execution due to a integer overflow (CVE-2021-38185, bsc#1189206) UPDATE: This update was buggy and could lead to hangs, so it has been retracted. There will be a follow up update. [...]- Patch with conflicting packages
Information for patch openSUSE-SLE-15.3-2022-333: ------------------------------------------------- Repository : Update repository with updates from SUSE Linux Enterprise 15 Name : openSUSE-SLE-15.3-2022-333 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : needed Category : security Severity : important Created On : Fri Feb 4 09:30:32 2022 Interactive : reboot Summary : Security update for xen Description : This update for xen fixes the following issues: - CVE-2022-23033: Fixed guest_physmap_remove_page not removing the p2m mappings. (XSA-393) (bsc#1194576) - CVE-2022-23034: Fixed possible DoS by a PV guest Xen while unmapping a grant. (XSA-394) (bsc#1194581) - CVE-2022-23035: Fixed insufficient cleanup of passed-through device IRQs. (XSA-395) (bsc#1194588) Provides : patch:openSUSE-SLE-15.3-2022-333 = 1 Conflicts : [22] xen.src < 4.14.3_06-150300.3.18.2 xen.noarch < 4.14.3_06-150300.3.18.2 xen.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.noarch < 4.14.3_06-150300.3.18.2 [...]
The above patch conflicts with the affected or vulnerable versions of 22 packages. If any of these affected or vulnerable packages are installed, it triggers a conflict, and the patch is classified as needed.
zypper patch
tries to install all available patches. If it encounters problems, it reports them, thus informing you that not all updates are installed. The conflict can be resolved by either updating the affected or vulnerable packages or by removing them. Because SUSE update repositories also ship fixed packages, updating is a standard way to resolve conflicts. If the package cannot be updated—for example, because of dependency issues or package locks—it is deleted after the user's approval.
To list all patches regardless of whether they are needed, use the option
--all
additionally. For example, to list all patches with
a CVE number assigned, use:
>
zypper list-patches --all --cve
Issue | No. | Patch | Category | Severity | Status
------+---------------+-------------------+-------------+-----------+----------
cve | CVE-2019-0287 | SUSE-SLE-Module.. | recommended | moderate | needed
cve | CVE-2019-3566 | SUSE-SLE-SERVER.. | recommended | moderate | not needed
[...]
9.1.4.3 Installing new package versions #
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 the following command:
>
sudo
zypper update
zypper update
ignores problematic packages.
For example, if a package is locked, zypper update
omits the package, even if a higher version of it is available. Conversely,
zypper patch
reports a conflict if the package is
considered vulnerable.
To update individual packages, specify the package with either the update or install command:
>
sudo
zypper update PACKAGE_NAME>
sudo
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 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:
>
sudo
zypper list-updates --all
To find out why a new package cannot be installed, use the zypper
install
or zypper update
command as described
above.
9.1.4.4 Identifying orphaned packages #
Whenever you remove a repository from Zypper or upgrade your system, some packages can get in an “orphaned” state. These orphaned packages belong to no active repository anymore. The following command gives you a list of these:
>
sudo
zypper packages --orphaned
With this list, you can decide if a package is still needed or can be removed safely.
9.1.5 Identifying processes and services using deleted files #
When patching, updating, or removing packages, there may be running processes
on the system which continue to use files having been deleted by the update
or removal. Use zypper ps
to list processes using deleted
files. In case the process belongs to a known service, the service name is
listed, making it easy to restart the service. By default zypper
ps
shows a table:
>
zypper ps
PID | PPID | UID | User | Command | Service | Files
------+------+-----+-------+--------------+--------------+-------------------
814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
| | | | | | /lib64/libdl-2.1->
| | | | | | /lib64/libpthrea->
| | | | | | /lib64/libc-2.19->
[...]
PID: ID of the process |
PPID: ID of the parent process |
UID: ID of the user running the process |
Login: Login name of the user running the process |
Command: Command used to execute the process |
Service: Service name (only if command is associated with a system service) |
Files: The list of the deleted files |
The output format of zypper ps
can be controlled as
follows:
zypper ps
-s
Create a short table not showing the deleted files.
>
zypper ps -s PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix 2031 | 2027 | 1000 | tux | bash |zypper ps
-ss
Show only processes associated with a system service.
PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix
zypper ps
-sss
Only show system services using deleted files.
avahi-daemon irqbalance postfix sshd
zypper ps
--print "systemctl status %s"
Show the commands to retrieve status information for services which might need a restart.
systemctl status avahi-daemon systemctl status irqbalance systemctl status postfix systemctl status sshd
For more information about service handling refer to
Chapter 19, The systemd
daemon.
9.1.6 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:
>
zypper repos
# | Alias | Name | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-15-GEO | SLEHA-15-GEO | Yes | No
2 | SLEHA-15 | SLEHA-15 | Yes | No
3 | SLES15 | SLES15 | 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
9.1.6.1 Adding repositories #
To add a repository, run
>
sudo
zypper addrepo URI ALIAS
URI can either be an Internet repository, a network resource, a directory or a CD or DVD (see https://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 it needs to be unique. Zypper will issue a warning if you specify an alias that is already in use.
9.1.6.2 Refreshing repositories #
zypper
enables you to fetch changes in packages from
configured repositories. To fetch the changes, run:
>
sudo
zypper refresh
zypper
By default, some commands perform refresh
automatically, so you do not need to run the command explicitly.
The refresh
command enables you to view changes also in
disabled repositories, by using the --plus-content
option:
>
sudo
zypper --plus-content refresh
This option fetches changes in repositories, but keeps the disabled repositories in the same state—disabled.
9.1.6.3 Removing repositories #
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
SLEHA-12-GEO
from Example 9.1, “Zypper—list of known repositories”, use one of the following commands:
>
sudo
zypper removerepo 1>
sudo
zypper removerepo "SLEHA-12-GEO"
9.1.6.4 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:
>
sudo
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 firefox
:
>
sudo
zypper renamerepo 'Mozilla Firefox' firefox
9.1.7 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
. To get information regarding particular packages,
use the info
command.
9.1.7.1 Searching for software #
The zypper search
command works on package names, or,
optionally, on package summaries and descriptions. Strings wrapped in
/
are interpreted as regular expressions. By default,
the search is not case-sensitive.
- Simple search for a package name containing
fire
>
zypper search "fire"- Simple search for the exact package
MozillaFirefox
>
zypper search --match-exact "MozillaFirefox"- Also search in package descriptions and summaries
>
zypper search -d fire- Only display packages not already installed
>
zypper search -u fire- Display packages containing the string
fir
not followed bee
>
zypper se "/fir[^e]/"
9.1.7.2 Searching for packages across all SLE modules #
To search for packages both within and outside of currently enabled SLE
modules, use the search-packages
subcommand. This
command contacts the SUSE Customer Center and searches all modules for matching packages,
for example:
>
zypper search-packages package1 package2
zypper search-packages
provides the following options:
Search for an exact match of your search string:
-x
,--match-exact
Group the results by module (default: group by package):
-g,
--group-by-module
Display more detailed information about packages:
-d
,--details
Output search results in XML:
--xmlout
9.1.7.3 Searching for specific capability #
To search for packages which provide a special capability, use the command
what-provides
. For example, if you want to know which
package provides the Perl module SVN::Core
, use the
following command:
>
zypper what-provides 'perl(SVN::Core)'
The what-provides
PACKAGE_NAME
is similar to
rpm -q --whatprovides
PACKAGE_NAME, 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.
9.1.7.4 Showing package information #
To query single packages, use info
with an exact package
name as an argument. This displays detailed information about a package. In
case the package name does not match any package name from repositories,
the command outputs detailed information for non-package matches. If you
request a specific type (by using the -t
option) and the
type does not exist, the command outputs other available matches but
without detailed information.
If you specify a source package, the command displays binary packages built from the source package. If you specify a binary package, the command outputs the source packages used to build the binary package.
To also show what is required/recommended by the package, use the options
--requires
and --recommends
:
>
zypper info --requires MozillaFirefox
9.1.8 Showing lifecycle information #
SUSE products are generally supported for 10 years. Often, you can extend that standard lifecycle by using the extended support offerings of SUSE which add three years of support. Depending on your product, find the exact support lifecycle at https://www.suse.com/lifecycle.
To check the lifecycle of your product and the supported package, use the
zypper lifecycle
command as shown below:
#
zypper lifecycle
Product end of support Codestream: SUSE Linux Enterprise Server 15 2028-07-31 Product: SUSE Linux Enterprise Server 15 SP3 n/a* Module end of support Basesystem Module n/a* Desktop Applications Module n/a* Server Applications Module n/a* Package end of support if different from product: autofs Now, installed 5.1.3-7.3.1, update available 5.1.3-7.6.1
9.1.9 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 a 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.
9.1.10 Troubleshooting #
If you have trouble accessing packages from configured repositories (for example, Zypper cannot find a certain package even though you know it exists in one of the repositories), refreshing the repositories may help:
>
sudo
zypper refresh
If that does not help, try
>
sudo
zypper refresh -fdb
This forces a complete refresh and rebuild of the database, including a forced download of raw metadata.
9.1.11 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
when committing changes to the file system to
create appropriate file system snapshots. These snapshots can be used to
revert any changes made by Zypper. See Chapter 10, System recovery and snapshot management with Snapper for
more information.
9.1.12 More information #
For more information on managing software from the command line, enter
zypper help
, zypper help
COMMAND or refer to the
zypper(8)
man page. For a complete and detailed command
reference, cheat sheets
with the most important commands,
and information on how to use Zypper in scripts and applications, refer to
https://en.opensuse.org/SDB:Zypper_usage. A list of
software changes for the latest SUSE Linux Enterprise Server version can be found at
https://en.opensuse.org/openSUSE:Zypper_versions.
9.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.
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
.
For several 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
and
gimp-devel
.
9.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 SUSE or from another trustworthy facility. This is
especially recommended for update packages from the Internet.
While fixing issues in the operating system, you might need to install a Problem Temporary Fix (PTF) into a production system. The packages provided by SUSE are signed against a special PTF key. However, in contrast to SUSE Linux Enterprise 11, this key is not imported by default on SUSE Linux Enterprise 12 systems. To manually import the key, use the following command:
>
sudo
rpm --import \ /usr/share/doc/packages/suse-build-key/suse_ptf_key.asc
After importing the key, you can install PTF packages on your system.
9.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, while -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. This is done 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. Afterward, delete all.rpmorig
and.rpmsave
files to avoid problems with future updates..rpmnew
files appear if the configuration file already exists and if thenoreplace
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 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 only 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. This command 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
.
9.2.3 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:
>
sudo
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:
>
sudo
applydeltarpm new.delta.rpm new.rpm
To derive it from the old RPM without accessing the file system, use the
-r
option:
>
sudo
applydeltarpm -r old.rpm new.delta.rpm new.rpm
See /usr/share/doc/packages/deltarpm/README
for
technical details.
9.2.4 RPM queries #
With the -q
option rpm
initiates
queries, making it possible to inspect an RPM archive (by adding the option
-p
) and to query the RPM database of installed packages.
Several switches are available to specify the type of information required.
See Table 9.1, “Essential RPM query options”.
|
Package information |
|
File list |
|
Query the package that contains the file FILE (the full path must be specified with 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 9.2, “rpm -q -i wget
”.
rpm -q -i wget
#Name : wget Version : 1.14 Release : 17.1 Architecture: x86_64 Install Date: Mon 30 Jan 2017 14:01:29 CET Group : Productivity/Networking/Web/Utilities Size : 2046483 License : GPL-3.0+ Signature : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82 Source RPM : wget-1.14-17.1.src.rpm Build Date : Thu 08 Dec 2016 07:48:34 CET Build Host : sheep09 Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> 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. Distribution: SUSE Linux Enterprise 15
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:
>
rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.14.1-lp151.13.10.x86_64
wget-1.19.5-lp151.4.1.x86_64
If only part of the file name is known, use a shell script as shown in Example 9.3, “Script to search for packages”. Pass the partial file name 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
PACKAGE displays a detailed list of change
information about a specific package, sorted by date.
With the installed RPM database, verification checks can be made. Initiate
these with -V
, 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:
|
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
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
.
9.2.5 Installing and compiling source packages #
All source packages carry a .src.rpm
extension (source
RPM).
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 processBUILD
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
.
Do not experiment with system components
(glibc
,
rpm
, 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.19.5.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:
-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.
Keep in mind that the BuildRoot
directive in the spec
file is deprecated. If you still need this feature, use the
--buildroot
option as a workaround.
9.2.6 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 several 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.
9.2.7 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 8, Installing or removing software.