The proper way to update Tumbleweed

Rolling distributions offer a significant advantage over their release-based brethren. By incorporating new packages as they become available, a rolling distribution can always offer current software while avoiding large, potentially traumatic upgrades. On the other hand, they subject the user to many small, potentially traumatic upgrades. One particular form of pain can come about when significant updates force changes in the set of installed packages. Recent discussions around the proper way to keep openSUSE Tumbleweed current illustrate that a certain amount of confusion exists around rolling-release updates.

Recently, a Tumbleweed user posted that "all hell broke loose" after updating a Tumbleweed system with "zypper dup". That led to a somewhat incredulous response:

A Tumbleweed user might be forgiven for not knowing that they should use that particular command; documentation on the subject is scarce, and questions on the topic abound. Understanding this response requires a brief digression into how openSUSE systems are managed.

The zypper command, which does package management on openSUSE systems, has two commands that can be used to update a system to current software: update (or "up") and dist-upgrade (or "dup"). The former will update existing packages in place but avoids making changes to the set of installed packages or the repositories those packages come from. The latter, instead, will try to track the current state of the distribution by adding or removing packages as needed.

Debian users will note the similarity with the apt-get upgrade and dist-upgrade commands. There, too, users often seem confused about the difference between the two, and it is not uncommon to see advice to the effect that dist-upgrade should be avoided. Trying to maintain a system on Debian testing, which is essentially a rolling distribution, without dist-upgrade tends to lead to updating difficulties over the long run, though.

With regard to zypper, users reading the man page for information about the --no-allow-vendor-change option will find it in a section marked: "Expert Options: Don’t use them unless you know you need them". Said user could probably be excused for shying away from this option, especially since the man page is not particularly detailed in its description of what it does. It is probably fair to say that most openSUSE users don't think of themselves as dealing with "vendors", among other things.

Those users are often accustomed to using unofficial repositories on their systems, though; the set of packages offered by Tumbleweed, while reasonably large, is smaller than those offered by, say, Debian or Fedora, but openSUSE makes it easy for anybody to set up their own repositories in the Open Build System. Hooking into a few of those repositories is often the only way to get all of the desired software installed without undergoing the indignity of building from source.

Use of these repositories can lead to trouble when using zypper dist-upgrade, though. The normal behavior of dist-upgrade is to search every configured repository for the newest version of each package in the system. That can cause a version of a package from one repository to be replaced by another version from a different repository; this change of source repository is the "vendor change" referred to. If a user added an unofficial repository to get one specific package, they may find, years later, that other packages from that repository have pushed aside the versions shipped by openSUSE — versions that the user might rather have kept.

There are two ways to avoid this sort of repository change. One is to use zypper update, which will not make those changes. But, as Richard Brown explained, this approach is not without its disadvantages:

That is why the consensus recommendation for Tumbleweed is to use dist-upgrade with the --no-allow-vendor-change option, regardless of whether one is an expert or not.

Of course, using dist-upgrade has its own challenges, in that it can cause significant changes to the system beyond the in-place updating of packages. But experience shows that this is a necessary evil that comes with tracking a rolling distribution. And, face it, it's also part of the fun and the thrill that comes with running such distributions. The result might be an occasional surprise, but the best thing to do is to just roll with it.

---

to post comments

##
## EXPERTS ONLY: TUNE DISTRIBUTION UPGRADE (DUP)
## Set whether to allow changing the packages vendor upon DUP. If you
## are following a continuous distribution like Tumbleweed or Factory
## where you use 'zypper dup --no-allow-vendor-change' quite frequently,
## you may indeed benefit from disabling the VendorChange. Packages from
## OBS repos will then be kept rather than being overwritten by Tumbleweeds
## version.
##
## Valid values:  boolean
## Default value: true
##
solver.dupAllowVendorChange = false

##
## EXPERTS ONLY: Per default the solver will not replace packages of
## different vendors, unless you explicitly ask to do so. Setting this
## option to TRUE will disable this vendor check (unless the application
## explicitly re-enables it). Packages will then be considered based on
## repository priority and version only. This may easily damage your system.
##
## Valid values:  boolean
## Default value: false
##
# solver.allowVendorChange = false