On a SUSE system, what is the difference between `zypper patch`, `zypper update` and `zypper dup`, and which one is the supported way to keep openSUSE Tumbleweed current?

## One solver, three intents SUSE's package manager is `zypper`, a front end to the `libzypp` library and its dependency solver. Unlike a package manager where "update everything" is a single idea, zypper exposes three distinct intents, and choosing the wrong one is the classic SUSE mistake. ## patch — the advisory is a first-class object On SUSE, a **patch** is not a package. It is a metadata object shipped in the update repository that says "to fix issue X, these package versions must be installed", and it carries attributes: a category (`security`, `recommended`, `optional`, `feature`, `document`), a severity, references to the bug or CVE it closes, and flags for whether applying it needs a reboot or a package-manager restart. That makes selective maintenance expressible: ```bash zypper list-patches --category security # what security advisories are pending zypper patch --category security # apply exactly those ``` This is the SLES-idiomatic command, because the enterprise maintenance model *is* a stream of issued patches against a fixed base: you are not chasing newer upstream versions, you are applying the fixes SUSE has published and tested for the release you are running. Other RPM distributions do carry advisory metadata too, but zypper makes the patch its own verb rather than a filter on update, which is the difference an interviewer is usually probing. Two exit codes matter when you script this. `zypper` returns **103** when the patch it just applied touched the package management stack itself, meaning you must run the command again to finish; and **102** when a patch requires a reboot to take effect. A maintenance script that ignores 103 silently leaves patches unapplied. ## update — newest version of what is already installed `zypper update` (`zypper up`) ignores advisories entirely and asks a simpler question: for each installed package, is a newer version available in an enabled repository? It is deliberately conservative — it will not delete an installed package in order to satisfy a dependency, and by default it does not chase a package into a different vendor's repository. When it cannot resolve an update without breaking that rule, it just leaves the package behind and tells you so. That conservatism is a feature on a fixed release and a trap on a rolling one. ## dup — make the system match the repositories `zypper dup` (`dist-upgrade`) hands the solver a different goal: the installed set should equal what the currently enabled repositories describe. To reach that state the solver may **downgrade** a package, **remove** one, or switch it to a different **vendor**. It is the only one of the three that can express "this package was renamed", "this library was split into three", or "this package no longer exists". Hence the rule that trips up newcomers: **Tumbleweed is updated with `zypper dup`, not `zypper update`.** A rolling stream reshapes its package set constantly, and `zypper update` cannot follow those transitions — it will grind to a half-updated state where some packages are new, others are pinned by unsatisfiable dependencies, and the system slowly diverges from anything SUSE has tested. `zypper dup` is also what you run when the set of repositories itself changes: upgrading Leap from one release to the next is "point the repositories at the new version, then `dup`", and the same command is how you deliberately move packages back to the distribution vendor after experimenting with a third-party repository. Vendor handling is configurable with `--allow-vendor-change` / `--no-allow-vendor-change`, and the default has shifted between zypper versions — so in automation, state it explicitly rather than relying on the default. ## Practical consequences - On SLES, a maintenance window is usually `zypper refresh` then `zypper patch`, re-run until it reports nothing pending, with 102/103 handled. - On Leap, `zypper update` for day-to-day currency; `zypper dup` for release upgrades. - On Tumbleweed, `zypper dup` always, and often. - Pinning is orthogonal: `zypper addlock <package>` records a lock (persisted under `/etc/zypp/locks`) and every one of the three commands honours it, reporting the conflict rather than quietly working around it. - After any large update, services can still be running against deleted library files; `zypper ps` is the SUSE-native way to see which ones need restarting. ## What the interviewer is checking The question is a proxy for "have you actually administered a SUSE box, or only read that zypper is SUSE's apt?". The distinguishing answers are: patch is an advisory object with categories, not a package; update is deliberately unable to remove packages; and dup is required on Tumbleweed precisely because it *can* remove and downgrade.