Ubuntu repository?


I was trying to upgrade rust and I realized that its extremely unpleasant experience.
The only ubuntu repository I’ve found is broken and outdated.
Rust website suggest to download binary and run some shell scripts to get it installed … this is madness,
and waste of everybody’s time (not to mention security issues).
Can I have official deb packages please?


The rustup script is fairly careful about avoiding the problems with installation-via-shell:

  • the script is served over https
  • binaries are signed and the signature is checked
  • the script is robust against truncations because it does no actual work until the very last line (and you’re free to download it, read over it, and then running too)
  • installing the compiler (by any route) means you’re literally going to be running executables distributed by the Rust team… that is, there’s a big element of trust even if you manage to avoid running our shell script
  • I believe a package can basically run arbitrary scripts as root (i.e. an official deb package will be just as dangerous in this respect)

https://blog.sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install.html is a great discussion of the general behaviour.

Security issues or otherwise aside, it is definitely nice to have tooling that helps with upgrading versions, such as your distro’s package manager. For Rust specifically, there’s the even more powerful multirust, which makes juggling/installing compiler versions super easy. For example, two common tasks:

  • when a new version comes out, getting it is as simple as multirust upgrade stable,
  • using nightly for a single command is just multirust run nightly ... (e.g. multirust run nightly cargo clippy to run cargo clippy to lint your code)

(I see you’ve found already found a relevant issue about packaging Rust.)


I don’t know about Ubuntu, but there are official .deb packages for Debian in the main Debian repository.


Rust website suggest to download binary and run some shell scripts to get it installed … this is madness,
and waste of everybody’s time (not to mention security issues).
Can I have official deb packages please?

You do realize that the only real benefit that official deb packages from the Rust project would provide is that you would be able to use apt-get instead of rustup.sh or multirust to update versions. Ultimately, however, either approach will just fetch the binary package, unpack it appropriately, and run some shell scripts to install it.

There is pretty much no security advantage to installing a deb from an upstream project (rather than from the repositories you already have keys for) over installing a tarball from an upstream project with some supporting scripts that handle checking signatures, uninstalling and upgrading it (which rustup.sh and multirust are).

There is a rustc package in Debian unstable and testing right now. So you can actually get official packages from Debian, if you prefer using a deb over the upstream distribution; and I do prefer that for anything that I’m going to be shipping and supporting for the long term. But if that’s not sufficient for you, because it’s not available for Ubuntu or Debian stable, I do recommend just using rustup.sh or multirust, as they work well and are just as secure as if the Rust project shipped an upstream deb.

  1. And thats IS BIG HELP. I’d have one way to upgrade apps on my development machine. I have over 1000 packages installed here and they are all upgradeable with one command. Can you imagine going to go to every website, click download and run shell script manually for 1000 packages? Package managers were invented for a reasone.

  2. Same thing applies for building customized docker images, deployment environments etc. - nearly all mature software projects I am using do have deb packages, so deploying them is unified regardless of where and how I want them to be deployed. Having custom ways of doing this is not really helpful.

Except that I have to trust that this script is indeed the thing I want to download. Don’t place the burden of proving this on me, use the tools that package management provides (automatic verification of checksums and keys).

Thanks, I didn’t know. But this doesn’t solve any of my problems. Look at elasticsearch for example - they provide their packages for ubuntu/debian, offering choice of selected stable/unstable versions for few recent releases of debian/ubuntu (not sure about other distros). Its the way it should be and I consider this to be the right thing to do.


Oh boy… I didn’t know that. So much work invested in reinventing package management, poorly.
I think I get it now. I can understand its useful on mac/win, but from linux point of view its insane
and extremely unfriendly.


I strongly disagree, multirust is much nicer than the system’s package manager (I say this as someone using Linux) as soon as you are using more than one version of Rust, which I find is fairly common e.g. the clippy example I give above, or developing multiple libraries where some need unstable features and some don’t.

Of course, you are entirely correct that having a distro package makes it easier to automatically configure machines.


Same here. multirust is a lifesaver.


What does it do that system package doesn’t?


It installs the stable, beta and nightly version of Rust and gives you the ability to switch between them very easily. This is important if for example:

  • You prefer to work on stable for most of your projects (as it should be) but need nightly features for one of your projects. Multirust lets you change the version you use with one command.
  • You want to run compiler plugins like clippy (very very useful linter). Compiler plugins only work on nightly, so if you want to develop you project on stable but still be able to use them you need a way to switch between the two quickly.


I may not get it, but I don’t see how its different from apt-get install rust1.5 rust1.6 rust-2016-02-20 rust-nigthly
and update-alternatives --config rust (well, maybe some rust-specialized way of setting symlinks/$PATH would be better for that) ?


There is not only Ubuntu. The Rust developers would have to maintain repositories for Ubuntu, Debian, Red Hat, SuSE, etc. etc.

I think it is reasonable to leave this to the distro vendors. Some already have very comprehensive support for different Rust versions that are installable in parallel.


Pick two of those, leave the rest for community, and you’ll cover vast portion of the market. Nobody expects rust to provide support on the same level for every distro out there. This is what many of db/service vendors do.


But that’s exactly what is provided currently, and conveniently.


The difference is that we are tied to distro release schedule, right? In case of debian it means rust there would be about 2 years old (if not more, I am not sure about their freezing schedules). That is the problem. I want distro of my choice (within reason, say all stable versions for past 2 years) with rust version of my choice, including nightly. And when new stable rust is released, I want it ASAP.


As others have said, it makes switching between versions much easier than update-alternatives. There’s the multirust run example I gave above, and it even allows per-directory overrides, so you can set up the default compiler used for each specific project and thus changes to the global environment won’t affect a project that relies on a specific Rust version.