Arch Linux User Repository

I apologise for the tone; reading it now I can see how it could be off-putting, though I did not intend that. I shall reflect on how I express myself online.

I find the tone and emphasis in your reply off-putting — I'm just a volunteer trying to do the best I can. However, I was operating under the assumption that it would update an existing stable installation when it was already present, and I was wrong. With that in mind I have removed the environment variable. I will gradually do the same for the other Rust packages I maintain as new releases are published.

But adding RUSTUP_TOOLCHAIN=stable doesn’t solve anything concerning the “I hadn’t run rustup update for a while” problem! If the user didn’t already have the stable toolchain installed, it’ll install an up-to-date stable toolchain, but updating it will be up to the user: so there’s no net gain there. If the user does already have the stable toolchain installed (whether due to manual action or a previous invocation like this one), there’s no guarantee it will satisfy the MSRV.

It seems to me that all it does is make it slightly more likely that it will compile the first time you install this package.

I could understand something like RUSTUP_TOOLCHAIN=1.38 (though I’d still probably remove it because I can), because that would actually mean something. But I remain convinced that RUSTUP_TOOLCHAIN=stable doesn’t actually achieve anything useful.

Hi @ChrisMorgan

Thanks for your thoughts. Here's some of the rationale for why I started including that in all the Rust packages I maintain.

I got complaints that packages didn't build and it was due to exactly the reason you describe. I.e. they hadn't run rustup update stable in a while and their compiler wasn't new enough. I set the variable to ensure that the latest stable compiler was used if rustup was available, which mirrors the behaviour of installing the rust package instead of using rustup.

Further, you don’t even know it will do anything, because you’re depending on Cargo, not rustup.

That is deliberate. If they are not using rustup then it will just use the version that's available. The most likely scenario in that case is that they have the rust package installed, which will track the stable version as well.

In allsorts-tools case, the minimal supported Rust version is 1.38.0. I don't think there's a good way to express that requirement via the PKGBUILD or Cargo.toml at the moment, so I went with latest stable as it seems like the common case for a rustup user is to track stable Rust. I'm sorry that this impacts your workflow.

Since this mirrors the behaviour of depending on the rust I'm inclined to leave it in for now.

I don’t reckon RUSTUP_TOOLCHAIN=stable is warranted, and request its removal. It doesn’t say anything about the version that you require (it could be “satisfied” by an ancient stable toolchain if I just haven’t run rustup update for a while), but indicates that you expect any up-to-date version to work. Further, you don’t even know it will do anything, because you’re depending on Cargo, not rustup.

As it is, I’m removing that from PKGBUILD manually because I don’t have a stable toolchain installed and don’t want to install another toolchain unnecessarily.