Zypper is the command-line package manager of openSUSE and SUSE Linux Enterprise. In Linux package management, it installs, removes, updates and queries RPM packages from configured repositories, and it resolves dependencies automatically through the libzypp library and its SAT-based solver.
Zypper plays the same role on SUSE systems that APT plays on Debian and DNF plays on Fedora. It shares its engine with the graphical YaST software module, offers patch-based updates for enterprise maintenance and handles the rolling-release upgrades of openSUSE Tumbleweed with a dedicated distribution upgrade command.
How Zypper resolves and installs packages
Zypper itself is a front end. The heavy work happens in libzypp, which downloads repository metadata, builds a pool of all available and installed packages and passes the request to libsolv, a solver that models dependencies as a Boolean satisfiability (SAT) problem. This approach finds a consistent solution quickly even with tens of thousands of packages.
When no clean solution exists, Zypper does not guess silently. It presents numbered solution options, such as removing a conflicting package or keeping an older version, and asks the administrator to choose. After confirmation, packages are downloaded, verified against GPG signatures and installed through the RPM database.
| Layer | Responsibility | Notes |
|---|---|---|
| Zypper | Command-line interface | Parses commands and shows results |
| libzypp | Repositories, metadata, transactions | Also used by YaST and PackageKit back ends |
| libsolv | Dependency resolution | SAT solver with fast pool handling |
| RPM | Install files, run scripts, keep the database | Low-level package format and tool |
Essential Zypper commands
Zypper commands have long names and short aliases, for example install and in, or refresh and ref. Most actions require root privileges, while search and info queries can run as a normal user.
| Command | Short form | Purpose |
|---|---|---|
| zypper refresh | ref | Update repository metadata |
| zypper install PKG | in | Install packages and dependencies |
| zypper remove PKG | rm | Remove packages |
| zypper update | up | Update installed packages within the same release |
| zypper dist-upgrade | dup | Upgrade the distribution, required on Tumbleweed |
| zypper patch | none | Apply official maintenance patches |
| zypper search TERM | se | Search package names and summaries |
| zypper addlock PKG | al | Prevent a package from being changed |
Useful global options include –non-interactive for scripts, –dry-run to preview a transaction without changing the system, and --download-only to fetch packages in advance. After updates, zypper ps lists processes that still use deleted files, showing which services need a restart.
Repositories, priorities and vendor changes
Repositories are defined in files under /etc/zypp/repos.d and managed with zypper addrepo, zypper modifyrepo and zypper repos. Each repository has a priority from 1 to 99, where a lower number means higher priority; the default is 99. When several repositories offer the same package, Zypper prefers the one with the higher priority.
Zypper also tracks the vendor of each package. By default, it will not silently switch an installed package from the official openSUSE vendor to a third-party repository such as Packman. Switching requires an explicit choice, for example zypper dup --from REPO --allow-vendor-change, which protects systems from accidental mixing of package sources.
| Situation | Recommended command | Reason |
|---|---|---|
| openSUSE Tumbleweed | zypper dup | Rolling release needs full distribution upgrades |
| openSUSE Leap point release | zypper up or zypper patch | Keeps the system within the release |
| SUSE Linux Enterprise server | zypper patch | Applies tested and classified fixes |
| Major Leap version upgrade | zypper dup after changing repositories | Moves the system to the new release |
Patches and maintenance on SUSE systems
A distinctive Zypper feature is the patch, a metadata object published by the distribution that groups the package updates needed to fix one problem. Each patch carries a category, such as security, recommended, optional or feature, and a severity rating, so administrators can apply exactly the fixes their policy requires.
Commands such as zypper list-patches --category security and zypper patch --cve CVE-ID let teams target specific vulnerabilities and document which advisories have been applied. Some patches update the package stack itself; Zypper installs those first and then asks to run again, which keeps the update tool consistent before other fixes are processed.
Patches that require a reboot or service restart are flagged in their metadata. In enterprise environments, this information feeds into maintenance windows and compliance reports, which is one reason SUSE administrators often prefer zypper patch over a plain package update.
Zypper compared with other package managers
All mainstream Linux package managers solve the same problem, but they differ in package format, solver design and update model. Zypper and DNF both use RPM, yet their repositories and conventions are not interchangeable between distributions.
| Tool | Distributions | Package format | Distinctive trait |
|---|---|---|---|
| Zypper | openSUSE, SUSE Linux Enterprise | RPM | Patches, vendor stickiness, libsolv |
| DNF | Fedora, RHEL and derivatives | RPM | Modular plugins, also uses libsolv |
| APT | Debian, Ubuntu | DEB | Very large repository ecosystem |
| Pacman | Arch Linux | Tar-based packages | Simple and fast, rolling release |
Universal formats such as Flatpak and Snap complement rather than replace Zypper: they deliver desktop applications with their own runtimes, while Zypper continues to manage the base system and its libraries.
Pitfalls and good practice
- Using zypper up on Tumbleweed can leave the system partially upgraded; the supported command is zypper dup.
- Mixing too many third-party repositories increases conflicts and unexpected vendor changes.
- Running dup with –non-interactive blindly can accept package removals that deserved review.
- Skipping snapshots: on Btrfs systems, Snapper creates pre- and post-transaction snapshots that allow a rollback, and they should stay enabled.
- Ignoring zypper ps after updates leaves services running old, vulnerable library code.
A plain-language summary
Zypper is the software installer and updater for SUSE Linux systems. An administrator types what is needed, and Zypper finds the program in trusted online stores called repositories.
It also works out what else the program depends on and installs those pieces too. Before anything changes, it shows a plan and asks for approval. It works like a careful shop assistant who checks that every part fits before handing over the order.
An example from practice
A system administrator maintains a dozen openSUSE Tumbleweed workstations in a design studio. Every Monday, a maintenance script runs zypper ref and then zypper dup --dry-run and sends the planned changes to the administrator, who reviews any proposed package removals.
One week, the dry run shows that a multimedia codec package would switch vendor because of a conflict with the Packman repository. The administrator resolves it by setting the Packman priority to 90 and confirming the vendor change explicitly. The real upgrade then runs, and Snapper records snapshots before and after the transaction.
On one workstation, a graphics driver regression appears after the upgrade. The administrator rolls back to the pre-update snapshot within minutes and locks the driver package with zypper al until a fixed version arrives. The outcome is a routine that keeps all machines current while limiting downtime to a single short reboot.