Bug 1213091

Summary:	patch:openSUSE-SLE-15.5-2023-2603-1.noarch wants to deinstall installed rust packages
Product:	[openSUSE] openSUSE Distribution	Reporter:	Stephan Hemeier <Sauerlandlinux>
Component:	Maintenance	Assignee:	William Brown <william.brown>
Status:	RESOLVED WORKSFORME	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	arvidjaar, meissner
Version:	Leap 15.5
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Stephan Hemeier 2023-07-06 17:22:21 UTC

The patch patch:openSUSE-SLE-15.5-2023-2603-1.noarch deinstalls rust and cargo packages:

zypper patch
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: the to be installed rustup-1.26.0~0-150400.3.7.1.x86_64 conflicts with 'rust+rustc' provided by the installed rust1.70-1.70.0-150400.9.3.1.x86_64
 Solution 1: Following actions will be done:
  deinstallation of rust1.70-1.70.0-150400.9.3.1.x86_64
  deinstallation of cargo1.70-1.70.0-150400.9.3.1.x86_64
  deinstallation of cargo-1.70.0-150400.24.18.1.x86_64
  deinstallation of rust-1.70.0-150400.24.18.1.x86_64
 Solution 2: deinstallation of rustup-1.24.3~git1.0a74fef5-150400.3.4.1.x86_64
 Solution 3: do not install patch:openSUSE-SLE-15.5-2023-2603-1.noarch

Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c

If I use Solution 2 it deinstalls rustup, but the new rustup is not installed:

LANG=C zypper se -s rustup
Loading repository data...
Reading installed packages...

S | Name   | Type       | Version                           | Arch   | Repository
--+--------+------------+-----------------------------------+--------+-------------------------------------------------------------
  | rustup | package    | 1.26.0~0-150400.3.7.1             | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
  | rustup | package    | 1.24.3~git1.0a74fef5-150400.3.4.1 | x86_64 | Main Repository
  | rustup | srcpackage | 1.26.0~0-150400.3.7.1             | noarch | Update repository with updates from SUSE Linux Enterprise 15

Whe I try to install rustup once more:

LANG=C zypper in rustup
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: the to be installed rustup-1.26.0~0-150400.3.7.1.x86_64 conflicts with 'rust+rustc' provided by the installed rust1.70-1.70.0-150400.9.3.1.x86_64
 Solution 1: Following actions will be done:
  deinstallation of rust1.70-1.70.0-150400.9.3.1.x86_64
  deinstallation of cargo1.70-1.70.0-150400.9.3.1.x86_64
  deinstallation of cargo-1.70.0-150400.24.18.1.x86_64
  deinstallation of rust-1.70.0-150400.24.18.1.x86_64
 Solution 2: do not install rustup-1.26.0~0-150400.3.7.1.x86_64

Choose from above solutions by number or cancel [1/2/c/d/?] (c):

Or is it wanted to not use rustup with installed rust and cargo packages?

Comment 1 Stephan Hemeier 2023-07-06 17:23:04 UTC

Same behavior on Leap 15.4 and 15.5.

Comment 2 Marcus Meissner 2023-07-07 08:55:20 UTC

let me refer to William our rust maintainer.

Comment 3 William Brown 2023-07-10 01:49:25 UTC

> Or is it wanted to not use rustup with installed rust and cargo packages?

Correct - rustup contains links to /usr/bin/rustc and /usr/bin/cargo which are proxy binaries to the true rust instances that rustup creates in your home dir. This is how packaged rustup avoids you needing to change your shell environment, and also avoids needing "rustup init" to install it's own proxies.

So as a result, it is intended that you choose either rustup OR rust/cargo from packages.

Generally it's also down to situation too. The role of these packages is different:

* rustup - you are a developer who wants to compile and build rust applications, and have access to IDE integrations
* cargo/rust - you are building packages and want to target the "latest" system rust toolchain.

So you should choose which one you install based on your use case in this situation.

Comment 4 Stephan Hemeier 2023-07-10 07:28:50 UTC

Thanks for clarification.

Comment 5 William Brown 2023-07-10 07:36:57 UTC

No problem. Let me know if you have any other issues.