Here’s the deal … everything worked fine until I “upgraded” by installing this as referenced in a previous thread
windeath:/home/dart # zypper in openSUSE-repos-Tumbleweed
Now when I do a “zypper dup” I get this:
Computing distribution upgrade…
9 Problems:
Problem: 1: problem with the installed Mesa-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 2: problem with the installed Mesa-dri-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 3: problem with the installed Mesa-gallium-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 4: problem with the installed Mesa-libGL1-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 5: problem with the installed Mesa-vulkan-device-select-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 6: problem with the installed libOSMesa8-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 7: problem with the installed libgbm1-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 8: problem with the installed libvulkan_intel-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 9: problem with the installed libvulkan_radeon-32bit-25.0.3-1699.415.pm.1.x86_64
Problem: 1: problem with the installed Mesa-32bit-25.0.3-1699.415.pm.1.x86_64
Solution 1: install Mesa-32bit-25.0.3-412.1.x86_64 from vendor openSUSE
replacing Mesa-32bit-25.0.3-1699.415.pm.1.x86_64 from vendor http://packman.links2linux.de
Solution 2: keep obsolete Mesa-32bit-25.0.3-1699.415.pm.1.x86_64
Etc…
But if I do
zypper dup --allow-vendor-change
I get this:
The following 4 NEW packages are going to be installed:
libmalcontent-ui-1-1 malcontent-control
ovpn-dco-kmp-default-0.2.20241216~git0.a08b2fd_k6.14.1_1-2.15 python313-argcomplete
The following package is going to be REMOVED:
ovpn-dco-kmp-default-0.2.20241216~git0.a08b2fd_k6.14.1_1-2.13
78 packages to upgrade, 10 to downgrade, 4 new, 1 to remove, 9 to change vendor.
Package download size: 511.2 MiB
Package install size change:
| 1.17 GiB required by packages that will be installed
-118.2 MiB | - 1.28 GiB released by packages that will be removed
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): ste code here
Why the difference? zypp.conf looks like this unchanged except for the first few lines so I don’t have to scroll down to do/undo something
windeath:/home/dart/Downloads # cat /etc/zypp/zypp.conf
## Configuration file for software management
## /etc/zypp/zypp.conf
##
## Boolean values are 0 1 yes no on off true false
## Experimental so setting it here instead of further down. 5 is default
download.max_concurrent_connections = 12
## my changes
solver.onlyRequires = true
# solver.allowVendorChange = true
## says the default is true
solver.dupAllowVendorChange = true
[main]
Why is “zypper dup --allow-vendor-change” not the same as “zypper dup” ? given the /etc/zypp/zypp.conf file?
The zypp.conf shipped by openSUSE contains override of the default which is not “at the top”. So, your setting “at the top” is most likely ignored and overridden by the line further down. Which is confirmed by the different behavior with and without explicit --allow-vendor-change.
Thank you … I also find it hard to believe that moving and uncommenting a line in the file would cause zypper to fail when the original line is commented out … this isn’t a “position sensitive” line of code … correct?
Ok … the line was commented out farther down so it had no effect … I actually did that on purpose without knowing why … there was no contradiction … I’ll double and triple check just because I usually do that anyway … what contradiction?
Ok…saw @hui and here is my diff between zypp.conf and zypp.conf.rpmnew … did I miss something? I’m getting a bit tired
dart@windeath:~> diff /etc/zypp/zypp.conf /etc/zypp/zypp.conf.rpmnew
4,13c4,5
< ## Boolean values are 0 1 yes no on off true false
<
<
< ## Experimental so setting it here instead of further down. 5 is default
< download.max_concurrent_connections = 12
< ## my changes
< solver.onlyRequires = true
< # solver.allowVendorChange = true
< ## says the default is true
< solver.dupAllowVendorChange = true
---
> ## - Boolean values are 0 1 yes no on off true false
> ## - Environment variables may overwrite corresponding config values
16c8,17
<
---
> ##
> ## If zypp is locked by another process this is the number of seconds to wait
> ## for the lock to become available. A negative value will wait forever. If the
> ## lock can not be acquired within the specified time an exception is raised.
> ##
> ## Valid values: number
> ## Default value: 0
> ## Environment variable: ZYPP_LOCK_TIMEOUT
> ##
> # lock_timeout = 0
219c220,221
< ## Default value: true
---
> ## Default value: false
> ## true on SUSE-15.6 and older
227c229
< # download.use_deltarpm = true
---
> # download.use_deltarpm = false
411c413
< # solver.onlyRequires = true
---
> # solver.onlyRequires = false
423c425
< # solver.allowVendorChange = true
---
> # solver.allowVendorChange = false
454,459c456
< ## 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.
---
> ## Set whether to allow changing the packages vendor upon DUP.
462c459
< ## Default value: true
---
> ## Default value: false (was true in Code12, libzypp-16.x)
464c461
< # solver.dupAllowVendorChange = true
---
> # solver.dupAllowVendorChange = false
Call it hubris but … I don’t think so … I could be wrong of course …
Thanks for the heads up That’s the way I like it too
Still playing with getting everything back to “normal”
(ie: the way I like my TumbleWeed ) gotta do a DUP/etc/drivers the hard way and run through everything just to doublecheck …
That’s the way I like it too
) gotta do a DUP/etc/drivers the hard way and run through everything just to doublecheck …