Bugzilla – Bug 1220407
zypper dup downgrades instead of upgrading
Last modified: 2024-03-25 09:59:40 UTC
zypper dup does do a downgrade instead of doing an upgrade, e.g.: Die folgenden 6 Pakete werden den Anbieter ändern: perl-common-sense 3.74-bp154.1.49 -> 3.5-150500.4.2.1 x86_64 -> noarch OSS-15.5-OBS_Server_2.10 openSUSE -> obs://build.opensuse.org/OBS perl-File-Sync 0.11-bp154.1.21 -> 0.11-150500.1.1 x86_64 OSS-15.5-OBS_Server_2.10 openSUSE -> obs://build.opensuse.org/OBS perl-GD 2.73-bp154.1.84 -> 2.51-150500.2.2.1 x86_64 OSS-15.5-OBS_Server_2.10 openSUSE -> obs://build.opensuse.org/OBS perl-JSON-XS 3.04-bp154.1.18 -> 2.34-150500.8.2.1 x86_64 OSS-15.5-OBS_Server_2.10 openSUSE -> obs://build.opensuse.org/OBS perl-Socket-MsgHdr 0.05-bp154.1.25 -> 0.04-150500.20.2.1 x86_64 OSS-15.5-OBS_Server_2.10 openSUSE -> obs://build.opensuse.org/OBS zypper does here a downgrade for perl-common-sense 3.74-bp154.1.49 -> 3.5-150500.4.2.1 instead of doing: perl-common-sense 3.74-bp154.1.49 -> 3.75-bp155.1.5 compare above downgrades with following available packages: S | Name | Type | Version | Arch | Repository --+--------------------+-------+-----------------+--------+----------------------- | perl-common-sense | Paket | 3.75-bp155.1.5 | x86_64 | openSUSE-Leap-15.5-Oss | perl-File-Sync | Paket | 0.11-bp155.2.10 | x86_64 | openSUSE-Leap-15.5-Oss | perl-GD | Paket | 2.76-bp155.1.7 | x86_64 | openSUSE-Leap-15.5-Oss | perl-JSON-XS | Paket | 4.03-bp155.1.5 | x86_64 | openSUSE-Leap-15.5-Oss | perl-Socket-MsgHdr | Paket | 0.05-bp155.2.11 | x86_64 | openSUSE-Leap-15.5-Oss so what is wrong here with zypper ?
Nothing is wrong. You are using a "third-party" OBS repo and zypper is performing a vendor-switch. By adding additional repos, you should be aware of repo priority and vendor-switch functionality.
@Christian DUP's job in the first place is to take care that all installed packages originate from one of the enabled repositories. The result should be similar to re-installing the system from the currently enabled repos. For this --allow-downgrade is enabled per default. The exact reason why the solver has chosen to pick a lower version can not be told in general. One needs to know the content of the system, the repositories and the packages dependencies. It's possible that other packages require the lower version in order to be updated. If you create and attach a solver testcase, we can have a look at it and probably find why the solver had chosen this solution. If you did not yet perform the dup, call 'zypper dup --debug-solver', then pack and attach the testcase directory zypper shows in it's output. If you already performed the dup there should be a testcase available in /var/log/updateTestcase-YYY-MM-DD-hh-mm-ss (the date the dup was perfomed).
Or try `zypper dup --no-allow-downgrade`. Maybe this already reveals the issue.
.