Packaging rustup for distros

There’s rewrite fish shell in rust discussion happening, and there’s this fine point being made about MSRV:

it's nicest when people who might just want to add a script that they want to test with the current state of the repo, who aren't really "into rust", can build it as easily as possible. And for people who aren't "into rust", the most straightforward thing is to use distro packages.

This seems like a very reasonable observation to me! The answer I want to give is

Readme should mention installing rustup package from the distro, and then rust-toolchain.toml would handle selecting the right version

However, while I know that rustup is packaged by, eg, NixOS and Arch, I don’t see a package for Ubuntu and Debian, the big ones.

What is the reason for that, why big distros don’t package rustup? Is this some ideological or architectural desire to not package package managers? Are there some specific technical issues with rustup which we can fix?


Or Fedora. Knowing Fedora better, I suspect it is more along the lines of shipping tools that the distro did not itself build using its guarantees. While rustup itself could be built fairly easily, its main purpose of shipping code that was not built by the distro (and being a much more "closed" set unlike the package hosting sites) can make it a harder sell.


More reason to (finally?) fold rustup into Cargo? Pretty sure the distros package things like pip and npm.


The equivalents for python/node would be pyenv and nvm, though they both have a much more fragmented ecosystem with multiple tools available. On Arch it looks like pyenv is available in the main repositories, but for nvm you have to go to the AUR. Neither are available on Ubuntu or Fedora.

rbenv is packaged GitHub - rbenv/rbenv: Manage your app's Ruby environment.

I would love to see rustup packaged for Debian.

My understanding is that the blocker is still that rustup is a bunch of crates that aren't on because they don't want to be perceived as providing a stable API, and that makes it difficult to package.


I am wondering why is that a blocker? Like, rustc isn't on, and cargo isn't meaningfully on It perhaps would be nicer to package rustup as you average binary like ripgrep, but packaging as an odd part of the bootstrap toolchain also feels fine...


Just "makes it difficult", not "makes it impossible".

It looks like there's an Intent To Package for debian from a month ago:


That's great to see!

I won't answer for others, but ... this may be related to perceptions (right or wrong) that rustup's goal is in direct conflict with the purpose of your typical packaging system (tracking dependencies, only having one version of a given package installed system-wide at a given time etc.).

There's perhaps the perception that a system-wide packaging system's purpose is to not encourage behaviour whih causes users to end up in a situation similar to what's described in xkcd: Python Environment

Important for @matklad's question about what rustup can do on the technical side to improve the packaging situation, this ITP mentions the download package as an issue.

Currently it's been patched out, but ideally it doesn't have to be. Both fedora and debian's tools have support for git dependencies, so the general blocker of rustup not being on is not relevant any more, but the download crate is also not there, which creates problems for these tools:

So ideally one would integrate the download crate into rustup.

The split was likely done to improve compile/iteration times. And doing this integration myself locally, it seems that it increases the cargo check time from 1.93 seconds to 2.13 seconds, so about 10% (talking about hot caches here, I first did cargo check, then added a blank line to the top of to do the benchmark). Obviously this isn't great...

Alternatively one can only upload the download crate to, even if it's internal (issue for that has been linked up-thread). Maybe under a different name, idk.

1 Like

Now, I'm definitely on the "manage all packages through a system package manager; say no to per-language package managers" side, but I don't think using rustup would make such a mess as that. :slight_smile: I'm not familiar with Python, but I guess that kind of mess (of different ways of installing Python) results from having a longer history and having to learn from one's own mistakes, whereas Rust was able to learn from other languages' mistakes.

I still expect distros will use their own packaged versions of Rust and Cargo to build packages for the distribution. But packaging rustup remains incredibly useful: it chains the root of trust of Rust to that of various distributions, and it allows installing cross-compilation toolchains and nightly toolchains.



1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.