zypper Install fails on vendor-change (from mirantis/launchpad)

[james-nesbitt]

Summary

PackageManager.Install on zypper (SLES/openSUSE) runs zypper install -y without --allow-vendor-change. As a result, installing any package whose only dependency-resolution solution replaces a package provided by a different vendor fails non-interactively: zypper presents the vendor-change solution, defaults to cancel, and exits 4. The install appears to fail for no clear reason.

This is a general rig behaviour, independent of what is being installed or which tool is driving rig — it affects any consumer whose install set obsoletes/replaces a distro-provided package from another vendor.

Mechanism

zypper, by default, will not switch a package's vendor during an install/upgrade unless explicitly told to. Interactively it prompts; non-interactively (-y/--non-interactive) it does not silently accept the vendor-changing solution — it cancels. rig always runs the non-interactive form, so the operation dead-ends with exit 4 and no actionable error.

Concrete example

One easy way to hit this: a stock SLES 15 SP7 cloud image (e.g. AWS suse-sles-15-sp7-*) ships SUSE's own containerd package pre-installed. Installing a third-party container-runtime package that obsoletes it (any vendor's containerd.io-style package from an add-on repo — Docker/Mirantis packages are one such case, but the vendor is irrelevant to the mechanism) triggers exactly this:

pm, _ := client.Sudo().PackageManager()
err := pm.Install(ctx, "containerd.io") // third-party repo already added

runs zypper install -y containerd.io, which resolves only to a vendor-change:

Problem: 1: the to be installed containerd.io-...x86_64 requires 'containerd.io-runc = ...',
but this requirement cannot be provided
 Solution 1: install containerd.io-minimal-... from vendor <third-party>
  replacing containerd-1.7.29-...x86_64 from vendor SUSE LLC
 Solution 2: do not install containerd.io-...
 Solution 3: break containerd.io-... by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c    # <- non-interactive default

Exit code 4, nothing installed. Re-running the same install with --allow-vendor-change succeeds (exit 0). This is not specific to any particular package, repo, or vendor — it is the general zypper vendor-change policy meeting rig's non-interactive install.

Why it matters

• Affects any rig-driven install on SLES/openSUSE where the resolver must cross a vendor boundary (common on cloud images that pre-install distro versions of tools an operator then wants to replace with an upstream/enterprise build).
• The failure is opaque: the exit-4 "cancel" gives no signal that a vendor change was the actual blocker.

Proposal / open question

Simplest fix: pass --allow-vendor-change on the zypper install action (draft PR attached).

This is deliberately aggressive about package adoption and may be undesirable as a global default — it lets zypper switch a package's vendor/origin on any install, weakening the same-vendor guarantee zypper gives out of the box. Open question for maintainers: is the unconditional flag acceptable, or would you rather gate it behind an opt-in install option (which means extending the PackageManager.Install signature/interface, a larger change affecting all managers and callers)? Happy to reshape the PR either way.

Written by AI: claude-sonnet-5

[james-nesbitt]

@kke created this to highlight a potential change. I will work around it in launchpad, but if you think that this change is warranted in the sles tooling, then I will downstream the change.

[james-nesbitt]

moved this change to #418.

Reopening this.