Lab Journal: The Mesa Conflict I Saw Coming — Tumbleweed Update, Round Two

Last month’s Tumbleweed post ended with a warning: Mesa was split between Packman and openSUSE, the same setup that broke VLC. Three weeks later, it bit. Here’s how one zypper command moved eight Mesa packages to a single vendor, how a 911-package upgrade went through cleanly, and how a Packman codec package slipped in through the back door anyway.

$ cat table_of_contents.txt

Last month’s Tumbleweed update post ended with a warning in “Next Up”: my Mesa graphics packages were split between Packman and openSUSE, the same setup that had caused a VLC dependency conflict. “If it bites, it’s the same fix.”

Three weeks later, it bit. This is the follow-up: the prediction, the fix, and one new surprise.

Snapshot Hygiene First

Before updating, I opened VMware’s Snapshot Manager, deleted last month’s “pre-update 2026-09-29” snapshot (the VM had run fine since), and took a fresh “pre-update 2026-10-19.”

Snapshots stack in a chain, and each one adds a layer the virtual disk has to track. Keep one safety net, not a pile of them.

Starting point:

ny2honolulu@tumbleweed-vm:~> grep VERSION_ID /etc/os-release
VERSION_ID="20260924"

(The hostname from last month’s cleanup stuck. No more localhost.)

The Prediction Comes True

ny2honolulu@tumbleweed-vm:~> sudo zypper dup
...
2 Problems:
Problem: 1: the to be installed Mesa-26.2.5-1699.2.pm.1.x86_64 requires 'Mesa-dri = 26.2.5',
but this requirement cannot be provided

Problem: 2: the to be installed libvulkan_lvp-26.2.4-1.1.x86_64 requires
'Mesa-vulkan-device-select = 26.2.4', but this requirement cannot be provided

Mesa is the graphics stack (OpenGL, Vulkan, video acceleration), and its packages must all be the same version. Mine were split, and the two sources had moved apart:

SourceMesa version available
Packman26.2.5
openSUSE26.2.4

My Packman Mesa wanted 26.2.5, but its partner Mesa-dri came from openSUSE, which only had 26.2.4. Meanwhile my openSUSE libvulkan_lvp wanted 26.2.4, but its partner was a Packman package. It was the same pattern as VLC: two repos moving at different speeds, with my packages caught in between.

Notice what was not in the problem list: VLC. Moving it fully to openSUSE last month fixed it for good.

I pressed c to cancel. zypper hadn’t changed anything yet.

Picking a Side

Last time I picked openSUSE without much thought. This time the choice deserved a reason.

Packman’s Mesa adds hardware video decoding for patented formats like H.264 and H.265. But this is a VMware VM. Its virtual graphics card doesn’t pass that hardware decoding through, so Packman’s build gives me essentially nothing here. openSUSE it is.

Finding the Whole Group

Lesson one from last month: don’t answer zypper’s numbered prompts one at a time. Find the full group and move it in one command.

ny2honolulu@tumbleweed-vm:~> zypper se -si Mesa libgbm libvulkan
S  | Name                      | Version            | Repository
---+---------------------------+--------------------+----------------------
i  | libgbm1                   | 26.2.3-1699.2.pm.1 | (System Packages)
i  | libvulkan1                | 1.4.357-1.1        | (System Packages)
i+ | libvulkan_lvp             | 26.2.3-1.1         | (System Packages)
i  | Mesa                      | 26.2.3-1699.2.pm.1 | (System Packages)
i  | Mesa-demo-egl             | 9.0.0-7.5          | Main Repository (OSS)
i  | Mesa-demo-x               | 9.0.0-7.5          | Main Repository (OSS)
i+ | Mesa-dri                  | 26.2.3-1.1         | (System Packages)
i  | Mesa-libEGL1              | 26.2.3-1699.2.pm.1 | (System Packages)
i  | Mesa-libGL1               | 26.2.3-1699.2.pm.1 | (System Packages)
i  | Mesa-libva                | 26.2.3-1699.2.pm.1 | (System Packages)
i  | Mesa-vulkan-device-select | 26.2.3-1699.2.pm.1 | (System Packages)

The -i flag limits results to installed packages. Searching three terms catches the Mesa pieces whose names don’t start with “Mesa.”

The group is the eight packages at version 26.2.3, all built from the same Mesa source. I left out two kinds of packages:

  • libvulkan1 (1.4.357) is the Vulkan loader, a separate project with its own versioning.
  • Mesa-demo-* (9.0.0) are test programs, also a separate project.

One Command

sudo zypper install --from download.opensuse.org-oss Mesa Mesa-dri Mesa-libEGL1 Mesa-libGL1 Mesa-libva Mesa-vulkan-device-select libgbm1 libvulkan_lvp

Unlike the VLC fix, there was no --oldpackage this time. With VLC, openSUSE’s build had the same version as Packman’s, and its smaller release number made it look like a downgrade. Here openSUSE’s 26.2.4 was newer than my installed 26.2.3, so it was a normal upgrade.

zypper printed a wall of “There is an update candidate … but it does not match the specified … repository” messages. That was it noticing Packman’s newer 26.2.5 and ignoring it, because --from told it to. The summary:

The following 6 packages are going to change vendor:
  libgbm1                    http://packman.links2linux.de -> openSUSE
  Mesa                       http://packman.links2linux.de -> openSUSE
  Mesa-libEGL1               http://packman.links2linux.de -> openSUSE
  Mesa-libGL1                http://packman.links2linux.de -> openSUSE
  Mesa-libva                 http://packman.links2linux.de -> openSUSE
  Mesa-vulkan-device-select  http://packman.links2linux.de -> openSUSE

8 packages to upgrade, 6 to change vendor.

The six Packman packages changed vendor, the two openSUSE ones simply upgraded, and nothing was removed.

The Big One: 911 Packages

With Mesa unified, sudo zypper dup went straight to the summary:

The following product is going to be upgraded:
  openSUSE Tumbleweed  20260924-0 -> 20261017-0

911 packages to upgrade, 19 new, 8 to remove.

Package download size:    1.56 GiB

Before saying yes, I checked three things.

The 8 removals. Each removed package had a matching new one: libbluray3 → libbluray4, libnettle8 → libnettle9, libPlasma7 → libPlasma8, and so on. When a library changes in a way that breaks compatibility, its “soname” number goes up, and the old one leaves once nothing needs it. That’s routine.

Disk space. With a 1.56 GiB download plus Btrfs snapshots that openSUSE takes automatically around updates:

ny2honolulu@tumbleweed-vm:~> df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        98G   11G   87G  11% /

Plenty.

Vendor changes. Two new VLC packages appeared in the NEW list (vlc-codecs, vlc-plugins-desktop), and I worried VLC was being pulled back to Packman. The totals line answered it: when there are vendor changes, zypper always counts them there (“6 to change vendor” in the Mesa summary). Here there was no such count, so there were zero vendor changes.

I pressed y. 938 actions completed: 911 + 19 + 8 = 938, so the numbers add up.

The Surprise: A Packman Package Sneaks In

After rebooting:

ny2honolulu@tumbleweed-vm:~> grep VERSION_ID /etc/os-release
VERSION_ID="20261017"
ny2honolulu@tumbleweed-vm:~> uname -r
7.2.11-1-default

The new snapshot and new kernel were both confirmed. Then I checked VLC:

ny2honolulu@tumbleweed-vm:~> zypper se -si vlc
S  | Name                | Version            | Repository
---+---------------------+--------------------+----------------------
i+ | vlc                 | 3.0.24-4.1         | Main Repository (OSS)
i  | vlc-codecs          | 3.0.24-1699.7.pm.3 | packman
i  | vlc-plugins-desktop | 3.0.24-4.1         | Main Repository (OSS)
...

(Trimmed. The other VLC packages were all OSS at 3.0.24.)

The good news is that openSUSE had caught up to VLC 3.0.24 and rebuilt phonon-vlc to match, which is the exact catch-up I’d been waiting on last month.

The surprise was vlc-codecs from Packman. Its status is i, not i+: I never asked for it. zypper installs recommended packages by default, and adding a new package doesn’t count as a vendor change, so it slipped past the check I’d just done. VLC was mixed-vendor again, which is fine today at matching versions but sets up the next conflict.

This is a lab VM. I don’t watch videos on it, so I removed and locked it:

ny2honolulu@tumbleweed-vm:~> sudo zypper rm vlc-codecs
The following package is going to be REMOVED:
  vlc-codecs

ny2honolulu@tumbleweed-vm:~> sudo zypper al vlc-codecs
Specified lock has been successfully added.

ny2honolulu@tumbleweed-vm:~> zypper ll
# | Name       | Type    | Repository | Comment
--+------------+---------+------------+--------
1 | vlc-codecs | package | (any)      |

Only vlc-codecs was listed for removal, which confirms nothing required it. The lock (al = “add lock”) stops future updates from re-installing it on a recommendation, and (any) means it applies no matter which repo offers it. To undo it: sudo zypper rl vlc-codecs.

A final zypper se -si vlc showed all ten VLC packages from Main Repository (OSS).

What I Learned

  • Writing down predictions pays off. Last month’s “Next Up” note turned into this month’s diagnosis in seconds.
  • Choose a vendor for a reason. Packman’s Mesa extras are hardware video features a VMware guest can’t use.
  • zypper se -si with several terms finds every member of a package group, including the ones with odd names.
  • Check the totals line for vendor changes, but know its blind spot: a new package from another vendor doesn’t count as one.
  • Recommended packages install automatically. i vs i+ tells you what you chose and what was chosen for you.
  • Locks are the fence. zypper al keeps an unwanted package out for good, and zypper ll shows what’s fenced off.

Next Up

  • Delete the “pre-update 2026-10-19” snapshot after a few days of normal use.
  • Packman now mainly supplies the FFmpeg libraries on this VM. With VLC and Mesa both single-vendor, the two groups that caused conflicts are settled, so the next dup should be boring. Boring is the goal.
  • The TOCTOU Concept Explainer promised last month is still on the list.