“zypper up” throws “Problem: cannot install both…”

English Applications
1

tl;dr: zypper up throws a “cannot install both…” error when I don’t want to install both; I want to update to the new one and discard the old one.

I’m using SLES 12 (this should not matter, the issue is package management), and trying to enable automatic (“zypper up”) updates for a package I support, let’s call it cli-tools. One of the dependencies is a kernel module called k-module. Because kABI compatibility is only an expectation within a service pack, a different version is needed for each SP. I installed version 2 of cli-tools while on SP4, and then migrated to SP5. You can see with zypper se -s that k-module was installed as a byproduct (“i”):

S  | Name                                      | Type       | Version                       | Arch   | Repository
  ---+-------------------------------------------+------------+-------------------------------+--------+----------------------
  v  | cli-tools                                 | package    | 3                             | x86_64 | repo
  i+ | cli-tools                                 | package    | 2                             | x86_64 | repo

  v  | k-module                                  | package    | 3                             | x86_64 | repo
  i  | k-module                                  | package    | 2                             | x86_64 | repo

When I run zypper up it throws:

The following 2 package updates will NOT be installed:
    cli-tools k-module

When I run zypper up cli-tools it says:


  Problem: cli-tools-3 requires k-module = source.version_4.12.14_122.20, but this requirement cannot be provided
    uninstallable providers: k-module-source.version_4.12.14_122.20-3[repo]

When I run zypper up k-module it throws:

Problem: cannot install both k-module-source.version_4.12.14_95.51-2.x86_64 and k-module-source.version_4.12.14_122.20-3.x86_64

  Solution 1: Following actions will be done:
  replacement of k-module-source.version_4.12.14_95.51-2.x86_64 with  k-module-source.version_4.12.14_122.20-3.x86_64
  deinstallation of k-module-source.version_4.12.14_95.51-2.x86_64

This is bizarre. I don’t want to install both of them: I want to replace version 2 with version 3. Indeed, if I select option 1, that’s exactly what happens: the new version gets installed, the old one deleted. But why can’t this be accomplished with just a simple zypper up? Any advice?

(Crossposted with https://stackoverflow.com/questions/61978623/zypper-up-throws-problem-cannot-install-both, will update either thread if an answer is provided.)

2

How I would do it:

rpm -e --nodeps oldpackageversion
zypper in newpackageversion
3

Unless I’m reading your post incorrectly,
The default behavior and what “zypper up” is telling you, is that both your cli-tools and its dependencies are being upgraded to the latest.
It’s not saying that both versions are being retained if that is your real question… It’s telling you that everything is being updated to newer versions.
It’s basically warning you that your old version is being replaced because it cannot exist side by side with the new version.

TSU

4

Why would you expect “zypper up” to retain both versions? In other words, why am I being warned that they can’t co-exist? I want “zypper up cli-tools” to just automatically update that package and its dependencies without saying:

The following 2 package updates will NOT be installed:
    cli-tools k-module
5

Oh, the difficulty is not in actually upgrading it. You can just do “zypper up k-module” and use Solution 1. But that’s not what I’m after: what I’m after is the package being automatically updated, with no user interaction, by an argument-less “zypper up”

6

I read the other post. I’m guessing you crossed a border (SP4->SP5) requiring distribution upgrade to be able to handle the update with no fuss. Did you try simply?:

zypper in package

Zypper knows how to substitute upgrade-to-new-version process for new install process when attempting to “install” a currently installed package.

7

“zypper in k-module” throws the same exact error as “zypper up k-module”: “Problem: cannot install both…”

8

If I run “zypper list-updates” I get nothing. But if I run “zypper list-updates --all” I get:

S | Repository            | Name                      | Current Version                 | Available Version             | Arch
--+-----------------------+---------------------------+------------------------------+-------------------------------+-------
v | repo                  | k-module | source.version_4.12.14_95.51-2  | source.version_4.12.14_122.20-3 | x86_64

I just don’t even see how there is a dependency issue. I uninstalled the packages that depend on k-module, so I can’t see what dependency barrier there could be to updating it to the newer one. Like, if there were a package that depended on a specific version of k-module, then I’d understand zypper preventing me from just changing the version of k-module without warning. But as far as I can tell, k-module is alone.

9

Sorry for multiple replies, but here’s a perhaps illuminating result.


zypper update --force-resolution  k-module

The following 2 NEW packages are going to be installed:
  k-module (version 3) k-module-tests (version 3)

The following 2 packages are going to be REMOVED:
  k-module (version 2) k-module-tests (version 2)

The following package is going to be upgraded:
  cli-tools

For whatever reason, zypper sees cli-tools as something that can be upgraded, but it sees k-module as something that cannot be upgraded; it must instead be uninstalled and reinstalled. Maybe this is related to k-module being a kernel module and the kABI changes in between service packs. Does anyone know how I’d go about investigating this more? It’s important to me that “zypper up” work without any user interaction beyond yes/no.

10

Post link to your kernel package, not some fictitious description. And post real output of zypper, not redacted variant. Any reply based on information so far will reflect how others interpret what you said, not your actual issue.

11

zypper will give you the Solution:

Problem: cannot install both k-module-source.version_4.12.14_95.51-2.x86_64 and k-module-source.version_4.12.14_122.20-3.x86_64

Solution 1: Following actions will be done:
replacement of k-module-source.version_4.12.14_95.51-2.x86_64 with k-module-source.version_4.12.14_122.20-3.x86_64
deinstallation of k-module-source.version_4.12.14_95.51-2.x86_64

But as arvidjaar says:
Post the complete output incl. the complete commandline and not any snipplet.

12

I’m sorry, for privacy reasons I can’t post the output totally unmodified. But I can assure you nothing meaningful is being lost in the translation.

That being said, I understand if you don’t want to spend time reading redacted output.

After some more investigation, I don’t think the answers actually lie in the output. I did an experiment that I think offers a better clue.

I downloaded k-module as a local .rpm file.

I ran “zypper in ./k-module.rpm” and it failed with the “cannot install both” versions error. I then ran “rpm -i ./k-module.rpm” and it installed successfully.

This raises the question: what is “zypper in” doing differently than “rpm -i” and why would “zypper in” fail where “rpm -i” succeeds? The zypper documentation doesn’t offer much help. If anyone knows anything, or can point me to any resources (including a specific spot in the source code), that would be much appreciated.

13

Again - post link to your RPM package.

14

Generally Linux will tell you when a possibly significant change is going to be made, which is why you’re warned and given options.
If you had some reason to retain the old version, you wouldn’t be happy if it was suddenly erased and replaced silently.

But,
There are easy ways to perform silent upgrades, updates and installs if that is what you want.
This is a common requirement for example when setting up machines using an install script when you don’t want to be bothered with each and every decision…

I describe some of those configurations in my small collection of zypper code…

https://en.opensuse.org/User:Tsu2/BASH_zypper

TSU