If you dig into the man pages for zypper, you will notice that zypper provides three distinct options for keeping your OpenSUSE system up-to-date; update (up), patch, and dist-upgrade (dup). If you aren’t familiar with zypper see my previous post managing packages with zypper for more information. In this post I will attempt to demonstrate the differences between each option and suggest when you may want to consider using each. In particular, I will try to explain the difference between a simple update and a patch, with emphasis on how to gather detailed information on particular patches.
Update
According to the man page, using zypper update (or zypper up) will; “Update installed packages with newer versions, where possible.†As long as updating the package will not cause a change in vendor (see dist-upgrade), using  zypper up will update every installed package to the newest version that is available in the repositories that are enabled on your system. Zypper update is a safe and reliable way to update any OpenSUSE or SUSE Enterprise Linux system, without worrying about major version changes.
To see a list of all available updates use zypper lu
zypper lu
Loading repository data…
Reading installed packages…
S | Repository | Name | Current Version | Available Version | Arch
–+————————+———————+—————–+——————-+——-
v | Main Update Repository | gimp | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | gimp-help-browser | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | gimp-lang | 2.8.18-1.4 | 2.8.18-2.3.1 | noarch
v | Main Update Repository | gimp-plugins-python | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | libgimp-2_0-0 | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | libgimpui-2_0-0 | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
For most users this is all you will probably ever need to know about keeping your OpenSUSE system updated.
If you are using OpenSUSE as your desktop OS you may notice that running “zypper up†will show more updates than you see through the GUI. This is because by default Yast Online Update (which is where the gui tools in gnome, and kde retrieve update information) only shows official software patches.
Patches
While patches in OpenSUSE are similar to updates in that they will install updated packages. Patches are meant for specific bug fixes and security fixes for software that comes packaged by OpenSUSE and is maintained in the Main Updates repository. A single patch might include several package updates to mitigate a specific security vulnerability or bug fix. In many cases installing patches will not fully update your system. A package with an updated version number that doesn’t match a “fix†for a bug or security flaw will not be included in a patch. Installing “Patches†rather than “Updatesâ€, strictly speaking, is probably only necessary for production environments that can only handle minimal changes to installed packages, while still maintaining a secure system. However, if you want to ensure that you have a stable and undisturbed desktop experience, there is certainly nothing wrong with limiting your updates to patches.
One of the great things about working with patches is the vast amount of information that is available for them that can be accessed straight from the command line. For example, if we wanted to know which cve’s (Common Vulnerabilities and Exposures) are currently affecting our system we could find out by using the “list-patches (lp)†option with zypper like this.
zypper lp --cve
Issue | No. | Patch | Category | Severity | Interactive | Status | Summary
——+—————+——————-+———-+———-+————-+——–+————————-
cve | CVE-2007-3126 | openSUSE-2017-462 | security | moderate | — | needed | Security update for gimp
This command gives us a lot of good information that can be useful for explaining the reasons that a patch is necessary. In this case, we see the cve number, the name of the patch (openSUSE-2017-462), its category (security), the severity (moderate), whether or not the patch is needed, and a quick summary (Security update for gimp).
We can take this a step further and pull down all the details of what packages will change if we patch this particular cve, by calling the info option with zypper and passing in the name of the patch we want to look at in this case “OpenSUSE-2017-462â€
zypper info openSUSE-2017-462
You can also send this command more specifically (but with identical output) as.
zypper info --type patch openSUSE-2017-462
When I’m writing a script I would tend to use the more verbose method, just so that the next person looking at it (or me 6 months later) will have a better chance of understanding what I was doing. Either way you choose to run this command you will receive output similar to this:
Information for patch openSUSE-2017-462:
—————————————-
Repository : Main Update Repository
Name : openSUSE-2017-462
Version : 1
Arch : noarch
Vendor : maint-coord@suse.de
Status : needed
Category : security
Severity : moderate
Created On : Wed 12 Apr 2017 05:15:35 AM EDT
Interactive : —
Summary : Security update for gimp
Description :
This update for gimp fixes the following issues:
This security issue was fixed:
– CVE-2007-3126: Context-dependent attackers were able to cause a denial of service via an ICO file with an InfoHeader containing a Height of zero
(bsc#1032241).
These non-security issues were fixed:
– bsc#1025717: Prefer lcms2 over lcms1 if both are available
– bgo#593576: Preven crash in PDF Import filter when importing large image PDF or specifying high resolution
Provides : patch:openSUSE-2017-462 = 1
Conflicts : [36]
gimp.i586 < 2.8.18-2.3.1
gimp.src < 2.8.18-2.3.1
gimp-debuginfo.i586 < 2.8.18-2.3.1
gimp-debugsource.i586 < 2.8.18-2.3.1
gimp-devel.i586 < 2.8.18-2.3.1
gimp-devel-debuginfo.i586 < 2.8.18-2.3.1
gimp-help-browser.i586 < 2.8.18-2.3.1
gimp-help-browser-debuginfo.i586 < 2.8.18-2.3.1
gimp-lang.noarch < 2.8.18-2.3.1
gimp-plugin-aa.i586 < 2.8.18-2.3.1
gimp-plugin-aa-debuginfo.i586 < 2.8.18-2.3.1
gimp-plugins-python.i586 < 2.8.18-2.3.1
gimp-plugins-python-debuginfo.i586 < 2.8.18-2.3.1
libgimp-2_0-0.i586 < 2.8.18-2.3.1
libgimp-2_0-0-32bit.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo.i586 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo-32bit.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0.i586 < 2.8.18-2.3.1
libgimpui-2_0-0-32bit.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo.i586 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo-32bit.x86_64 < 2.8.18-2.3.1
gimp.x86_64 < 2.8.18-2.3.1
gimp-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-debugsource.x86_64 < 2.8.18-2.3.1
gimp-devel.x86_64 < 2.8.18-2.3.1
gimp-devel-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-help-browser.x86_64 < 2.8.18-2.3.1
gimp-help-browser-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-plugin-aa.x86_64 < 2.8.18-2.3.1
gimp-plugin-aa-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-plugins-python.x86_64 < 2.8.18-2.3.1
gimp-plugins-python-debuginfo.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo.x86_64 < 2.8.18-2.3.1
As you can see this particular command string gives us plenty of details about the patch. Everything from basic information about the repository it will be coming from, to the date it was implemented, and a more full description including how the vulnerability may affect you. We can see both the security issues and non-security issues that are fixed. One of the potential points of confusion in the output comes in the last section “Conflicts :â€. The word “Conflicts†might seem to suggest that some of the currently installed packages conflict with updates that are needed to patch the vulnerability. This is not the way you should understand conflicts in this context. From the zypper man pages:â€A released patch conflicts with the affected/vulnerable versions of a collection of packages. As long as any of these affected/vulnerable versions are installed, the conflict triggers and the patch is classified as needed, optional or as unwanted if the patch is locked.†In proper context the conflict is a trigger to let us and the system know that an updated package is available to fix the vulnerability. So, in fact the conflict section can be read as a list of packages that are going to be updated, in order to remove the conflict.
To install all available patches you can simply run
sudo zypper patch
or to install patches to resolve a specific cve
sudo zypper install patch:openSUSE-2017-462
You can also list all patches that are categorized as “security†fixes.
zypper lp --category security
There are other ways to find patches that are available by listing bugzilla reports and severity, but I will let you find those on your own after you do a little more reading, and have become familiar with the commands listed here.
Distribution Upgrade (dup)
A distribution upgrade, performed by running:  sudo zypper dup , will upgrade (or downgrade) all installed packages to the latest version listed in every enabled repository, and as such, it should be used with caution. The upgrade operation will be performed regardless of vendor or repository and is often used when you want to replace an official package with one from a 3rd party repository, such as packman.
On a production system or system that needs to be kept in a stable state you will not want to use the dist-upgrade option except in certain situations. Most likely one of these:
- Upgrading from one OpenSUSE stable release to another i.e. (Leap 42.1 to Leap 42.2)
- Switching packages from one vender repo to another i.e. (OpenSUSE to packman)
- You are using Tumbleweed and want to keep your system up-to-date.
- Ostensibly you could still use zypper up
- I have found some documentation that would suggest using zypper dup with special switches whenever you update under Tumbelweed (Â
sudo zypper dup --no-allow-vendor-change ) https://en.opensuse.org/Portal:Tumbleweed
I very rarely use the dist-upgrade option on my own systems, though I hear it is more common with the rolling release (Tumbleweed).
I would highly recommend spending some time reading the zypper man pages if you are planning to do any serious work with zypper. As I’ve said before zypper is a great (probably the best) package manager that is available in any Linux distribution. It is a powerful tool that makes managing packages easier and faster than anything else that I’ve worked with.
Luke has an RHCSA for Red Hat Enterpirse Linux 7 and currently works as a Linux Systems Adminstrator in Ohio.
This post, re-published here with permission, was originally published on Luke’s site here.
Leave a Reply