Applies to SUSE Linux Enterprise Server 15 SP2 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 21.1, “Definition of Terms”. 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. 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: Global OptionsAdditionally, you can choose from one or more global options by typing them immediately before the command: > sudo zypper --non-interactive patch In the above example, the option --non-interactive means that the command is run without asking anything (automatically applying the default answers). Command-Specific OptionsTo use options that are specific to a particular command, type them immediately after the command: > sudo zypper patch --auto-agree-with-licenses In 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, license will be accepted automatically. ArgumentsSome 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 mplayer Some 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 Zypper subcommands are executables that are stored in the zypper_execdir, /usr/lib/zypper/commands. If a subcommand is not found in the zypper_execdir, Zypper automatically searches the rest of your $PATH for it. This enables writing your own local extensions and storing them in userspace. 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 <none> View the help screen for a subcommand: > zypper help appstream-cache To install or remove packages, use the following commands: > sudo zypper install PACKAGE_NAME > sudo zypper remove PACKAGE_NAME Warning: Do Not Remove Mandatory System Packages Do not remove mandatory system packages like glibc , zypper , kernel . If they are removed, the system can become unstable or stop working altogether. 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:MozillaFirefox Where mozilla is the alias of the repository from which to install. By Package Name Using Wild CardsYou 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 Packages When 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 CapabilityFor 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 VersionTogether with a capability, you can specify a hardware architecture and a version:
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 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 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 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. 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 6.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: 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. 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. Note: Disabled Installation Media 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. To verify whether all dependencies are still fulfilled and to repair missing dependencies, use: 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. 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 Chapter 1, Upgrade Paths and Methods. Patching SUSE Linux Enterprise is the most reliable way to install new versions of installed packages. It guaranties 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: 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 confirmed 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. 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 PatchesTo list all needed patches (patches that apply to your system but are not yet installed), use list-patches: > zypper list-patches Loading repository data... Reading installed packages... Repository |Name |Version |Category |Status |Since |Summary ------------------+-----------+--------+---------+--------+----------+--------------------------- SLES15-SP2-Updates|SUSE-2020-8|1 |applied |needed |2020-04-02|openssl: Update for OpenSSL Note the new Since column. From Zypper 1.14.36, this shows when a patch was installed. List of All PatchesTo 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 NumberTo 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 --bugzilla=CVE-2016-2315,CVE-2016-2324 List retracted patchesIn 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 Kernel See 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 : 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 packagesInformation 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 : 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, due to 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 [...] 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: Important 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: Note that this command only lists packages that match the following criteria:
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. 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. 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-> [...]
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-ssShow 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-sssOnly 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 15, The systemd Daemon. 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: The result will look similar to the following output: Example 6.1: Zypper—List of Known Repositories # > 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: 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. zypper enables you to fetch changes in packages from configured repositories. To fetch the changes, run: Note: Default Behavior of 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. 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 6.1, “Zypper—List of Known Repositories”, use one of the following commands: > sudo zypper removerepo 1 > sudo zypper removerepo "SLEHA-12-GEO" 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:
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 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. 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 fireSimple search for the exact package MozillaFirefox > zypper search --match-exact "MozillaFirefox" Also search in package descriptions and summariesOnly display packages not already installedDisplay packages containing the string fir not followed be eTo 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:
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. 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 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-30 SUSE Linux Enterprise Server 15 SP2 n/a* Module end of support Transactional Server Module 2022-07-30 Basesystem Module n/a* Desktop Applications Module n/a* Server Applications Module n/a* Extension end of support SUSE Package Hub 15 n/a* Package end of support if different from product: autoyast2-installation Now, installed 4.2.29-1.3, update available 4.2.31-1.8 bluez Now, installed 5.48-11.31, update available 5.48-11.34 branding-SLE Now, installed 15-17.77, update available 15-17.83 cantarell-fonts Now, installed 0.111-1.5, update available 0.111-1.8 checkmedia Now, installed 5.3-1.49, update available 5.3-1.52 cpupower Now, installed 5.5-2.12, update available 5.5-2.14 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. 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: 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. 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 7, System Recovery and Snapshot Management with Snapper for 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. 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. Tip: Software Development Packages 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. 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. 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:
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. 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. 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 6.1, “The Most Important RPM Query Options”. Table 6.1: The Most Important RPM Query Options #
For example, the command rpm -q -i wget displays the information shown in Example 6.2, “rpm -q -i wget”. 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 6.3, “Script to Search for Packages”. Pass the partial file name to the script shown as a parameter when running it. Example 6.3: Script to Search for Packages # #! /bin/sh for i in $(rpm -q -a -l | grep $1); do echo "\"$i\" is in package:" rpm -q -f $i echo "" done The command rpm -q --changelog 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: Table 6.2: RPM Verify Options #
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). 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) SPECSfor the .spec files, similar to a meta Makefile, which control the build process BUILDall the sources are unpacked, patched and compiled in this directory RPMSwhere the completed binary packages are stored SRPMShere 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: System Integrity 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. -bcDo the same as -bp, but with additional compilation. -biDo 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. -bbDo 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. -baDo 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-circuitSkip 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, the BuildRoot directive in the spec file is deprecated since SUSE Linux Enterprise Server 12. If you still need this feature, use the --buildroot option as a workaround. For more detailed background information, see the support database at https://www.suse.com/support/kb/doc?id=7017104. 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. |