Page MenuHomeSolus

Rustup package is missing symlinks
Open, Needs TriagePublic

Description

Context:
On Rust's Discord channel @dtm421 reported issue with error when using RLS:
found crate unicode_segmentation compiled by an incompatible version of rustc
After investigation it became clear the reason was rustup package from Solus repository.

The problem:
The error occurred because IDE calls rustup run <toolchain_name> rls which leads to toolchain installed by rustup but the cargo, rustc in PATH are coming from rust package resulting in the clash.
Arch Linux solved it by creating necessary symlinks pointing to rustup and making rustup conflict with rust.
For the reference installing from https://rustup.rs creates proxy binaries inside ~/.cargo/bin and adds it to the PATH.

Possible solutions:

  1. Create symlinks like Arch Linux does and make the package conflict with rust.
  2. Make rustup create proxy binaries in ~/.cargo/bin even if installed via package manager.

Event Timeline

mati865 created this task.Aug 2 2019, 10:56 AM

I'd say we can make rustup conflict with rust.

  • Solution nr.2 is not viable: eopkg shall never touch users' files, and also...
  • "Installing from rustup website creates proxy binaries inside ~/.cargo/bin and adds it to the PATH." means that rustup-installed binaries are being loaded after the "original" ones in PATH, thus shadowing them, so for this reason it would be pointless to have both "original" rust and rustup's.

@Girtablulu what do you think?

yea seems the most sane approach to let it conflict with rust and as you said $HOME is a place we are going to stay away :)

I also think option #1 would be better as immediate fix but let me explain something.

Solution nr.2 is not viable: eopkg shall never touch users' files, and also...

It doesn't have to be eopkg. Rustup binary could do it just like it does when installing using official method.

means that rustup-installed binaries are being loaded after the "original" ones in PATH, thus shadowing them, so for this reason it would be pointless to have both "original" rust and rustup's.

It's possible to make system Rust binaries available in rustup by running rustup toolchain link system /usr and use them afterwards with cargo +system build or whatever command you want. I do not expect users to benefit from it but it could be useful for Solus maintainers.

Hello, I'm the maintainer of rustup in Solus.
I have to admit that I am quite unexperienced with Solus packaging. However, I am willing to learn :)

To me it seems more simple to mark rust as conflict.

It's possible to make system Rust binaries available in rustup by running rustup toolchain link system /usr and use them afterwards with cargo +system build or whatever command you want. I do not expect users to benefit from it but it could be useful for Solus maintainers.

This could be very nice, but by doing so, this would end up some strange situations in which two different versions are installed together (one provided by Solus and another one installed in $HOME). By the way, this command updates some configuration files in $HOME, which we all don't want.

So, in my opinion, option 1 is better.

Guess we have a reasonable amount of opinions now. Let's allow Core Team decide :)