Tumbleweed’s New Package Roundup Is a Reason to Preview the Whole Upgrade

Tumbleweed’s recent snapshots combine a desktop update, new Qt libraries, a kernel change and a PHP security fix. Treating that as a collection of unrelated app updates misses how the rolling distribution is delivered. Before accepting the next upgrade, preview the complete transaction and check what your enabled repositories are asking it to change.

First separate the recap from the staging list

The October 30 openSUSE community roundup revisits week 43 and its five snapshots: 1016, 1017, 1018, 1020 and 1021. It names Plasma 6.8.0, Qt 6.12.0, Linux 7.2.11, Mesa 26.2.5 and PHP 8.5.12 among the arrivals. The PHP update addresses the PHP2Shell remote-code-execution flaws.

That is the period covered by the recap, not a claim that every listed package was released on October 30. The same roundup also identifies staging work on GNOME 51.1, kernel 7.3.0, Ruby 4.0.9, Go 1.27.3 and VirtualBox 7.2.22. A staging entry does not establish that the package has reached the snapshot available to your computer.

Architecture matters too. Our earlier Tumbleweed ARM report follows a different sequence of hardware and virtual-machine fixes. Compare the architecture and installed package versions before assuming two machines share the same update state.

Preview a distribution upgrade

The openSUSE Support Database specifies zypper dist-upgrade, shortened to zypper dup, for Tumbleweed. It explains that the operation brings the system into line with its repositories, including libraries and core tools as well as the kernel.

1. Before changing packages, keep a current backup and make sure you understand the system’s Snapper recovery route, if configured.
2. Open a terminal and run sudo zypper dup --dry-run to test the proposed transaction without installing or upgrading packages.
3. Read the summary for removals, renames, downgrades and dependency questions, rather than checking only the download size.
4. If a proposed change is unexpected, review the enabled repositories and resolve the reason before running the real upgrade.

The dry-run option tests the transaction. It does not prove that a graphics driver, extension or application will work after reboot. It gives you a chance to catch an unintended package change before installation.

Keep repository choices visible

Without a repository restriction, the documented distribution upgrade considers all defined repositories and re-evaluates dependencies. It can downgrade packages or handle package splits and renames as part of matching that state. More recent version numbers are not the only possible outcome.

Once the proposal makes sense, use the documented normal upgrade route and follow any reboot instruction. Recheck the desktop, graphics and services you actually rely on afterward. For this group of snapshots, an apparently successful desktop login alone would leave the PHP service and library-dependent applications untested.