This already happened twice, when I try to update my system I have conflicts with graphic things.
In this particular case I have issues with mesa, mesa-dri and mesa-dri-32bit, which is why I put this in hardware, as far as I know mesa is amd driver stuff.
I tried to keep the obsolete things momentarily, just to update the other things, but I get to the point where keeping old things is not an option.
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
3 Problems:
Problem: the installed Mesa-32bit-23.1.2-1699.353.pm.1.x86_64 requires 'Mesa = 23.1.2', but this requirement cannot be provided
Problem: the installed Mesa-23.1.2-1699.353.pm.1.x86_64 requires 'Mesa-dri = 23.1.2', but this requirement cannot be provided
Problem: the to be installed Mesa-32bit-23.1.3-353.1.x86_64 requires 'Mesa-dri-32bit = 23.1.3', but this requirement cannot be provided
Problem: the installed Mesa-32bit-23.1.2-1699.353.pm.1.x86_64 requires 'Mesa = 23.1.2', but this requirement cannot be provided
Solution 1: Following actions will be done:
install Mesa-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
install Mesa-gallium-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-gallium-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
Solution 2: install Mesa-23.1.2-1699.353.pm.1.i586 despite the inferior architecture
Solution 3: keep obsolete Mesa-23.1.2-1699.353.pm.1.x86_64
Solution 4: break Mesa-32bit-23.1.2-1699.353.pm.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 3
Problem: the installed Mesa-23.1.2-1699.353.pm.1.x86_64 requires 'Mesa-dri = 23.1.2', but this requirement cannot be provided
Solution 1: Following actions will be done:
install Mesa-libGL1-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-libGL1-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
install Mesa-gallium-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-gallium-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
Solution 2: install Mesa-dri-23.1.2-1699.353.pm.1.i586 despite the inferior architecture
Solution 3: keep obsolete Mesa-dri-23.1.2-1699.353.pm.1.x86_64
Solution 4: break Mesa-23.1.2-1699.353.pm.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 3
Problem: the to be installed Mesa-32bit-23.1.3-353.1.x86_64 requires 'Mesa-dri-32bit = 23.1.3', but this requirement cannot be provided
not installable providers: Mesa-dri-32bit-23.1.3-353.1.x86_64[download.opensuse.org-oss]
Mesa-dri-32bit-23.1.3-353.1.x86_64[openSUSE-20230620-0]
Solution 1: Following actions will be done:
keep obsolete Mesa-gallium-23.1.2-1699.353.pm.1.x86_64
keep obsolete Mesa-libGL1-23.1.2-1699.353.pm.1.x86_64
Solution 2: Following actions will be done:
install Mesa-dri-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-dri-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
install Mesa-gallium-32bit-23.1.3-353.1.x86_64 from vendor openSUSE
replacing Mesa-gallium-32bit-23.1.2-1699.353.pm.1.x86_64 from vendor http://packman.links2linux.de
Solution 3: deinstallation of steam-1.0.0.78-1.2.x86_64
Solution 4: install Mesa-gallium-23.1.2-1699.353.pm.1.i586 despite the inferior architecture
Solution 5: install Mesa-libGL1-23.1.2-1699.353.pm.1.i586 despite the inferior architecture
Solution 6: break Mesa-32bit-23.1.3-353.1.x86_64 by ignoring some of its dependencies
I would like to understand how to tackle these situations on my own so that in the future I can take care of it without bugging anyone and maybe even offer help to those who need it, but I’m a bit of a slowpoke and I can’t figure this out on my own.
inferior architecure = don’t = breaking things = never
break not good ? don’t
keep, obsolete is an option, until the new driver is released
Actually, these issues mostly appear if one repository is faster at updating the content then the other.
So you can actually wait it out, until the main repository has the required updates.
Thank you very much I will install from vendor and hope everything will just work fine.
When it’s not an option how long would things take if I decide to wait it out a bit?
I’m mostly using Leap, where I rarely see these. But I also have Tumbleweed installed, and I do see conflicts there.
My normal practice is: never take the option that breaks a package. That usually means keeping the obsolete package. Sometimes, that’s enough and the problem clears up after a few days. But if the same conflict keeps coming back, then I eventually have to make the hard decision. And it can be a difficult decision to make.
How someone decides to set priority for an Repo is what someone want.
If someone want some packages from Packman, but not switching to all installed packages to the Packman Version, someone will set Packman priority to low, f. e. 120.
Other want to switch all packages to Packman Version and set priority to 20.
That depends on what you want.
priority is only used by installing a non installed packages or f. e. reinstalling a package with zypper install --force
Also allow-vendor-change in the config depends also on what someone want.
It’s not the best solution, only one solution.
Also in my opinion on Tumbleweed a service for updating is also not the best choice…
And for someone who is asking here about conflicts it is not the best solution…
Do not make it even more confusing than it is already. Vendor switch has absolutely nothing to do with priorities. If some wants some packages from Packman then someone installs these packages from Packman. Without messing with priorities.
Some words of caution, in general, about “I learned from this video”.
First off, that video is from 2018. It’s now 2023, so five years ago. Although an okay “intro to priority levels” video, there’s other considerations with “dup”.
Even in the video, they mention, “due to recent changes” (paraphrasing). Keep in mind, there might have been more change(s) in the last five years.
Okay video for users first learning zypper, but don’t “take it to heart”.
This is usually not the best choice at all. Others have touched on the subject in this thread, if we choose to install a package from packman, it’s because its provides a feature we want. If it would be fine to switch those packages to the main OSS repo, then it’s a hint that we don’t need packman at all. We would be probably running flatpak apps in a openSUSE Kalpa or Aeon setup.
IME, when Packman packages are involved, the problem is usually transitory, meaning the PM mirrors are in a state of change. Wait somewhere between 5 minutes and 5 hours and the problem(s) will disappear on their own. If you feel compelled and don’t want to wait to get the easy ones upgraded, quit the dup, run an up, then wait before trying dup again. The up process might even consume all the time needed for the mirrors to finish getting consistent so you can try ref (if autoref is disabled, like I have with Packman) and dup again.
With space-limited slow old PCs that don’t get their dups on a regular basis, and download in advance can’t be counted on to find enough available space, it’s common for mirror content to change while a dup is in process, often “losing” Packman packages that were supposedly available when dup was started, and getting not found errors when their times come to be fetched and installed. Thus waiting “fixes” the problem.
Ever since the last major patent expiration, I’ve been disabling Packman on most installations. It can throttle some Mesa hassles caused by needing to use dup on TW when only one or a select few PM packages are needed or wanted among the many available in both standard and PM repos, while you normally want to keep AllowVendorChange enabled.
It seems that packman servers for building 32-bit packages are down, and been so for several days at the moment. That’s why Mesa-32bit and related packages are not yet updated in packman (the latest version is 23.1.2), while 64-bit Mesa packages are updated to version 23.1.3, causing the conflict.
I’m currently staying on a week-old snapshot because changing the vendor to openSUSE is the only viable solution, but I don’t want to risk breaking video acceleration in 32-bit applications, even if I’m unsure if I need it at all.
So, I’m waiting for them to be updated when packman maintainers fix their stuff. No big deal, people have been saying positive things about not updating Tumbleweed for a while. The snapshot approach is really solid.
I will install from vendor and hope everything will just work fine.