Atleast 20-40 mesa conflicts in latest dup

[40476]

atleast 20-40 mesa conflicts in latest dup

usr_40476@localhost:~> sudo zypper dup
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: 1: the to be installed Mesa-32bit-24.2.7-1699.396.pm.1.x86_64 requires 'Mesa = 24.2.7', but this requirement cannot be provided
not installable providers: Mesa-24.2.7-1699.396.pm.1.i586[packman]
                   Mesa-24.2.7-393.1.x86_64[repo-oss]

Problem: 2: the to be installed Mesa-libGL1-32bit-24.2.7-1699.396.pm.1.x86_64 requires 'Mesa-32bit = 24.2.7', but this requirement cannot be provided
not installable providers: Mesa-32bit-24.2.7-1699.396.pm.1.x86_64[packman]
                   Mesa-32bit-24.2.7-393.1.x86_64[repo-oss]

Problem: 3: the installed Mesa-libGL1-32bit-24.2.6-1699.395.pm.1.x86_64 requires 'libgallium-24.2.6.so', but this requirement cannot be provided
deleted providers: Mesa-dri-32bit-24.2.6-1699.395.pm.4.x86_64


Problem: 1: the to be installed Mesa-32bit-24.2.7-1699.396.pm.1.x86_64 requires 'Mesa = 24.2.7', but this requirement cannot be provided
not installable providers: Mesa-24.2.7-1699.396.pm.1.i586[packman]
                   Mesa-24.2.7-393.1.x86_64[repo-oss]

 Solution 1: Following actions will be done:
  keep obsolete Mesa-24.2.6-1699.395.pm.1.x86_64
  keep obsolete Mesa-gallium-24.2.6-1699.395.pm.4.x86_64
  keep obsolete Mesa-32bit-24.2.6-1699.395.pm.1.x86_64
 Solution 2: install Mesa-24.2.7-393.1.x86_64 from vendor openSUSE
  replacing Mesa-24.2.6-1699.395.pm.1.x86_64 from vendor http://packman.links2linux.de
 Solution 3: deinstallation of Mesa-32bit-24.2.6-1699.395.pm.1.x86_64
 Solution 4: install Mesa-24.2.7-1699.396.pm.1.i586 despite the inferior architecture
 Solution 5: break Mesa-32bit-24.2.7-1699.396.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/5/s/r/c/d/?] (c): 

the others show up after trying to install the new packages

[hui]

Basic search…

Discover can't update MESA and others -Dependencies Resolution Failed

Unfortunately some missinformation got spread in this thread. The issue is that the external Packman repository, which is not under control of openSUSE, provides inconsistent package versions of Mesa. This happens really often and the forum is full of it. Unfortunately the Packman maintainers does not really care about the quality of the package set they provide. So it often happens that inexperienced users stumble across this mess caused by the external Packman repository. It doesn’t matter if…

[40476]

is it safe to add --allow-vendor-change as a default? If so i would like to do that to make this less of a hassle in the future

btw the flag fixed my problem

[arvidjaar]

@40476

is it safe to add --allow-vendor-change as a default?

Define “safe”.

If you needed to install packages from a specific “vendor”, you probably needed some functionality that is not available in the same packages from different “vendors”. Allowing zypper to silently switch to a different vendor means you suddenly lose this functionality without even being aware of it.

Whether it is “safe” or not is up to you to decide. But if you do not care whether you have this functionality or not, why have you switched vendor in the first place?

[40476]

Well seeing as it broke me system and had to do a rollback due a bad OpenSUSE package I think maybe I will just wait a week until I update again

[hui]

You should read the linked thread before you claim that it is the fault of openSUSE. Packman is not under control of openSUSE. It is important to understand the meaning and consequences which come with 3rd party repositories.

[Sauerland]

PS The 32bit not build bug for the Packman Mesa packages should be solved today.