Manage packages with Zypper

Zypper is the command-line package manager of openSUSE and SUSE Linux Enterprise. This page gives you the commands really useful day to day: install, update, manage repositories, apply security patches and get a system with broken metadata back on its feet. It is written for an administrator who already knows apt or dnf and has to operate a SUSE machine. Two classic traps are covered explicitly, because they remove packages or let vulnerabilities through: the confusion between orphaned and unneeded packages, and the false idea that zypper patch only installs security fixes.

What you will learn

• Install, search for and remove a package with Zypper's basic commands.
• Update a SUSE system and choose between zypper update and zypper dist-upgrade.
• Add, disable and prioritise a software repository.
• Apply security patches by filtering the patches correctly.
• Tell apart orphaned packages from unneeded packages before any cleanup.
• Diagnose a corrupted cache, a broken dependency or a blocking lock.

The commands on this page were checked on openSUSE Leap 16.0 with Zypper 1.14.101, last measured on 30 September 2026. The short aliases (in, up, lr, ref) work everywhere, but the long forms are kept here for readability.

Install and update packages

This is the heart of the daily work. The read commands (search, info) require no privilege: run them with your normal account. The commands that modify the system (install, remove, update) require sudo, since they write to the RPM database and to the system directories.

Start by searching for the package, then check what it contains before installing it:

zypper search htop
zypper info htop

zypper search looks in the name and the description of the packages of the enabled repositories. zypper info shows the available version, the source repository, the installed size and the state (installed or not). On Leap 16.0, the output announces Version : 3.5.3-bp160.1.1 from repo-oss (16.0), and must show Installed : No as long as the package is not present.

Installing and removing take two commands:

sudo zypper install htop
sudo zypper remove htop

Zypper displays a transaction summary (packages added, dependencies pulled in, disk space) and waits for a confirmation. It is the right moment to reread what is going to be touched, especially when a simple installation causes the removal of another package.

For updates, Zypper offers two commands that do not do the same thing at all, and the choice has consequences:

Command	What it does	When to use it
sudo zypper update	Updates the installed packages to a newer version when possible. Does not change vendor, removes nothing.	Leap and SLE, routine maintenance
sudo zypper dist-upgrade	Performs a distribution upgrade: accepts vendor changes, removals and package renames.	Tumbleweed (rolling release), Leap version upgrade

Swipe to see more

Put simply, zypper update is conservative: if something has to be uninstalled to move forward, it prefers to do nothing. zypper dist-upgrade (alias dup) is authoritative: it aligns the system with what the repositories offer, even if that means removing packages. On Tumbleweed, it is the expected command; on a Leap or SLE server in production, zypper update is the right routine.

sudo zypper update
sudo zypper update htop

You can restrict the update to a single package by naming it. Then check with zypper info htop that the installed version matches the one announced by the repository.

dist-upgrade is not an update++

On a Leap or SUSE Linux Enterprise server, running zypper dist-upgrade out of habit can switch packages to a third-party repository and remove others. Keep this command for Tumbleweed and for deliberate version upgrades, after a backup or a snapshot.

Manage software repositories

A repository is a source of packages identified by a URL and an alias. Everything Zypper can install comes from an enabled repository, so the first thing to do on an unknown machine is to look at where its packages come from.

zypper repos
zypper lr -d

zypper repos (alias lr) lists the repositories with their alias, their state (enabled or not), the GPG check and the priority. The -d option adds the full URL and automatic refresh. A repository without a GPG check should alarm you: it installs unsigned packages.

Adding a repository always follows the same pattern, URL then alias. The URL depends on the version: on Leap 16.0, the directory is called 16.0/, and openSUSE_Tumbleweed/ on Tumbleweed:

sudo zypper addrepo https://download.opensuse.org/repositories/multimedia:/libs/16.0/ multimedia-libs
sudo zypper refresh

The refresh downloads the metadata of the new repository and asks you to accept its GPG key. Without this step, Zypper ignores the repository: it does not know yet what it contains. To remove a repository that is no longer needed, sudo zypper removerepo multimedia-libs is enough.

The priority settles conflicts when two repositories provide the same package. It is a source of confusion, so remember the rule: the smaller the number, the higher the priority. The default value is 99 on all the repositories of a standard installation, which zypper lr -p confirms on a fresh Leap 16.0.

sudo zypper modifyrepo --priority 90 multimedia-libs
zypper lr -p

Here, priority 90 puts multimedia-libs ahead of the official repositories left at 99. It is exactly what you want for a codec repository that must provide its own versions. The output of zypper lr -p must show 90 in the Priority column.

Finally, you can disable a repository without removing it, which is handy to isolate a problem without losing its configuration:

sudo zypper modifyrepo --disable multimedia-libs
sudo zypper modifyrepo --enable multimedia-libs

Security patches: what patch really does

This is the point where many documents get it wrong, including widely shared cheat sheets. A patch in the SUSE sense is an update packaged by the vendor with metadata: a category (security, recommended, optional, feature, document, yast) and a severity (critical, important, moderate, low).

The two commands below filter nothing by default:

zypper list-patches
sudo zypper patch

zypper list-patches lists all the applicable patches, not only the security fixes. zypper patch installs all the needed patches, all categories combined: on a fresh Leap 16.0 container, list-patches announces 2 patches needed (0 security patches). Believing the opposite leads to two symmetrical errors: thinking you "only" fixed security when you pushed functional changes, or wrongly believing that a machine subject to an audit only received security fixes.

To work only on security, the filtering is explicit and mandatory:

zypper list-patches --category security
sudo zypper patch --category security

The --category option (short form -g) restricts to the patches of the requested category. A useful variant filters on severity rather than on category, for instance to handle urgently only the most serious ones:

sudo zypper patch --severity critical --severity important

Check the result by running zypper list-patches --category security again: the output must announce that no security patch is applicable. If you are working on a specific CVE reported by a scanner, Zypper can target it directly:

zypper list-patches --cve=CVE-2024-6387
sudo zypper patch --cve=CVE-2024-6387

Once the patches are applied, the processes already running keep using the old libraries loaded in memory. An OpenSSL patch has no effect on a service still running with the old version:

sudo zypper ps -s

zypper ps lists the processes using files deleted by the latest updates, and -s produces a short table, without the list of files, where the Service column gives the name of the systemd service concerned. Restart those services (sudo systemctl restart <service>), or the machine if the kernel was updated. Until this step is done, the patch is not really applied.

Certification skill

Managing patches by category is part of the core expected in Linux administration exams. The reflex to remember is the pair apply then check: zypper patch --category security followed by zypper ps -s, never one without the other.

Cleaning up: orphaned and unneeded are not the same thing

Two options of zypper packages are regularly confused, and the mistake is costly: it gets software you still want removed.

Option	What it really shows	Should you remove them?
--orphaned	The installed packages that no longer belong to any configured repository (nor update candidate).	No, not automatically
--unneeded	The packages nothing depends on anymore: pulled in as dependencies, now useless.	Yes, after review

Swipe to see more

An orphaned package is not an unneeded package. It is a package Zypper can no longer find in the repositories: an RPM installed by hand, software from a repository you removed, or a package dropped during a version upgrade. It may very well be essential to your service. Mass-removing the output of --orphaned is the best way to uninstall a monitoring agent or a proprietary driver still in use.

zypper packages --orphaned

The Repository column of the output shows @System, which means exactly that: this package no longer comes from any known repository. Handle the list case by case, asking for each line where the package came from and whether it is still used.

The real cleanup, that of dependencies that became useless (the equivalent of apt autoremove), goes through --unneeded:

zypper packages --unneeded
sudo zypper remove package_name

Reread the list before removing: a package can be "unneeded" in the solver's sense while you use it on the command line, simply because it was installed as a dependency and never marked as wanted. On Tumbleweed, the upgrade can do this housekeeping along the way with sudo zypper dist-upgrade --remove-orphaned.

Never chain orphaned and remove blindly

The shortcut zypper packages --orphaned followed by a zypper remove of the whole list circulates widely. It destroys the packages installed outside any repository, third-party agents and drivers included. If you want to reclaim space, the right option is --unneeded, and you reread the list before confirming.

Lock a package and target a repository

Some operations require freezing a package, typically a kernel or application agent version validated by a vendor, that automatic updates must not move. Zypper calls this a lock.

sudo zypper addlock kernel-default
zypper locks
sudo zypper removelock kernel-default

zypper locks lists the active locks with their number, which you can pass directly to removelock. A forgotten lock is a frequent cause of "an update that does not install without a clear message": when a package stubbornly refuses to move, look at this list first.

The other recurring need is to switch a set of packages to a specific repository, for instance the multimedia codecs:

sudo zypper dist-upgrade --from multimedia-libs

The --from option restricts the upgrade to the named repository: the other packages stay where they are. It is the clean way to change vendor for a family of packages without touching the rest of the system.

Troubleshooting common problems

Zypper is reliable, but incidents look alike from one machine to the next. Here are the three most frequent symptoms in production, with the probable cause and the command that puts things back in order.

Symptom	Probable cause	Fix
Valid metadata not found or a repository failing on refresh	Corrupted or stale metadata cache	sudo zypper clean --all then sudo zypper refresh --force
Installation refused for a missing dependency or broken package	Inconsistent RPM database after an interrupted operation	sudo zypper verify
A package refuses to update, without an explicit error	Lock set on the package	zypper locks then sudo zypper removelock package_name

Swipe to see more

The clean then refresh pair is the first reflex: sudo zypper clean --all empties the metadata and package caches, and sudo zypper refresh --force forces a full reload from the repositories. This solves the vast majority of download errors, including after a mirror URL change.

When the system stays inconsistent, sudo zypper verify checks the dependencies of all the installed packages and offers to install or remove what is needed to repair. Read its proposal before accepting: it is a diagnosis, not a magic wand.

If a file of a package has been deleted or damaged, force the reinstallation rather than tinkering with the file by hand:

sudo zypper install --force openssh

The --force option reinstalls the package even if it is already present in the same version. The /var/log/zypper.log log (the complete history of transactions and errors) remains the best source when the terminal output is not enough: sudo less /var/log/zypper.log.

Finally, on an openSUSE installation on Btrfs with snapper, each Zypper transaction creates a snapshot before and after. It is the safety net that lets you go back after an update that breaks booting:

sudo snapper list
sudo snapper rollback ID

The rollback restores the system state to the given snapshot number and requires a reboot. Before running it, check that the chosen line is indeed the "pre" of the faulty transaction, in the Description column of snapper list.

Where Zypper comes from

Zypper was born in the openSUSE project in 2006, with openSUSE 10.2. The tools of the time (YaST2, rug, zen-updater) were considered slow and ill-suited to updates over the internet. SUSE therefore built libzypp, the library that resolves dependencies, and Zypper as its command-line client. This shared engine explains why Zypper and the YaST graphical interface always make the same decisions: they rely on the same solver.

Key points

• zypper update is conservative (no removal); zypper dist-upgrade accepts vendor changes and removals. Keep dup for Tumbleweed and version upgrades.
• zypper list-patches and zypper patch handle all the applicable patches, not only security. The --category security filter (or --severity) is mandatory to target security fixes.
• After a patch, zypper ps -s reveals the services still loaded with the old libraries. Without a restart, the fix is not active.
• packages --orphaned = packages outside any repository (manual RPM, removed repository). Never remove them in bulk.
• packages --unneeded = packages nothing depends on anymore. That is where the real cleanup is, the equivalent of apt autoremove.
• For repositories, a lower priority number wins; the default value is 99.
• Broken cache: zypper clean --all then zypper refresh --force. Inconsistent dependencies: zypper verify. Frozen package: zypper locks.
• On Btrfs, snapper rollback is the safety net after an update that breaks booting.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →