Consider packaging rustup

[postmodern]

It would help users install rustup if it were packaged (deb, rpm, dmg) and/or available via their package manager (homebrew). Package managers also offer many benefits, such as safety, security, dependency management, installing configuration files (ex: bash completions), uninstalling, and most provide a GUI. At first rustup could be made available via a 3rd party repository and the rustup.sh script could handle adding the appropriate repository to the user's package manager (see CriticalStack's installer script). Long term, rustup could be accepted into the major package repositories (Debian, Ubuntu, Fedora, Arch Community Repo, homebrew, etc).

To get started, see Ubuntu's Packaging Guide, Fedora's Creating an RPM guide, or the wonderful fpm utility.

[postmodern]

Also recently learned that Windows supports two package managers.

[steveklabnik]

This is usually the job of the distributions, not of the project itself. And some already are; Arch, for example: https://www.archlinux.org/packages/?sort=&q=rustup&maintainer=&flagged=

[postmodern]

Arch Linux's package repository is Community driven, so I'm not surprised someone has already packaged rustup. :) If you want rustup packaged by other Linux distros, you need to submit a request, usually to their bug tracker (see Debian RFP, Ubuntu's launchpad instructions, Fedora's pkgdb2 instructions). It speeds up the approval process when upstream has already done the work of packaging the software. It might be faster to package rustup ourselves and offer a PPA or Copr repository in the meantime, a la HandBrake. Also, providing your own repository would allow you to push new package versions immediately, instead of waiting on the distribution's QA process. It should be far less effort to get rustup into homebrew or uploaded to Chocolatey.

[steveklabnik]

Most of the people packaging rustc/cargo are already looking into it; it's unclear which distros will end up packaging rustup, as they want you to be using their own package manager. The Debian folks are working on "any cargo crate automatically turned into a debian package" for example...

[postmodern]

@steveklabnik then we should consider packaging rustup if no one else does :) As of writing this, Debian, Ubuntu and Fedora all have rustc packages, but no rustup (neither .sh or .rs) packages. Packaging rustup would help developers use specific versions of the Rust language that might not be available yet via the package manager. Although, I'm not sure whether distros would prefer a dynamically linked rust binary + shared crate libraries or one statically linked binary. Maybe this is something the rust community could take the lead on?

[est31]

If someone wants to package rustup for debian, @sylvestre has agreed to sponsor it.

[jethrogb]

Someone else brought this up on the forums: https://internals.rust-lang.org/t/package-repository-alternate-install-for-rustup/4529

And here's the direct link to the Arch package build script: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/rustup

[skade]

@jeffweiss made a good case on Twitter for packaging rustc/rustup as RPM/DEB and serving them through rmp/deb.rustup.rs: setup of CI environments and other environments using provisioning tools. They don't necesssarily care about the distribution-shipped versions, but also work much better with package distribution.

[est31]

While deb files sound nice with clean uninstall and stuff, I'd prefer if debian packaged rustup was kept the way it is (installing stuff itself):

• It would add complexity to rustup.rs
• Putting rustc/cargo/etc into deb would require superuser privileges to install and update new toolchains. part of why rustup is so great is that it does not need super user privileges. There is no security reason behind it, as long as my home is not mounted as noexec (which it usually is not).
• rustc/cargo/etc would be allowed through that to mess with my / directory. Even rustup itself doesn't mess with my / directory afaik.
• RPM/DEB files are often created for some super old ubuntu LTS version and then people assume they work on all ubuntu derivates, but in fact when then you try it, it is very well possible that you have bad luck and it has some incompatible dependency and suddenly you have to force installation and your system is broken, and you can't do sudo apt dist-upgrade/install without resolving that conflict, even if you tried to uninstall the DEB file.

[jeffweiss]

@est31 I wasn't advocating for deb packages for developer machines. rustup in those instances are entirely fine with me. My concern is around automation for CI machines. Maybe I'm not familiar with enough with the Rust ecosystem and/or rustup to be able automate installation of Rust toolchain for CI builds (which the fact that I would need to be, I would argue is a problem).

In my CI environment, I don't want the Rust toolchain in a user's environment, I want it in standard OS locations. I want my automation to be able to query if Rust is installed and which version using standard config management abstractions in Puppet, Chef, Ansible, etc, not trying to do which rustc and rustc --version and parsing the results, because that's bananas.

I don't really care if it's package(s) for rustup, rustc, and/or cargo that solve this problem. The existing release tarballs are already like 90% of what is necessary for this solution.

A prototype of creating a deb package can be done by

• unzip tarball and cd into extracted dir
• mkdir sandbox
• ./install.sh --destdir=sandbox --prefix=/usr
• mkdir sandbox/DEBIAN
• add the below as sandbox/DEBIAN/control
• dpkg-deb -b sandbox rust_1.16.0_amd64.deb

Prototype Debian control file

Package: rust
Version: 1.16.0
Section: main
Architecture: amd64
Depends: llvm
Priority: extra
Maintainer: Rust Core Team <info@rust-lang.org>
Description: Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
 Features:
  * zero-cost abstractions
  * move semantics
  * guaranteed memory safety
  * threads without data races
  * trait-based generics
  * pattern matching
  * type inference
  * minimal runtime
  * efficient C bindings

Here's an example of what would be great for Rust (prose for Windows and OS X sections truncated):

Installation

Windows

In addition to an .msi that we produce, there are Chocolatey packages available as well.

OS X

The homebrew packages are kept relatively up to date. You can install Rust with brew install rust. Afterwards, if you need the absolute latest version, you may run rustup.

Linux

We have different recommendations based on the role of the machine on which you're installing.

Developer

Developers often have the need to have multiple versions of the Rust toolchain installed: maintenance, pilot new Rust features, etc. Between using rustup as a concurrent toolchain version manager, shell tab completion installation, etc, we strongly recommend using rustup, which can be initially installed in these ways:

• curl ... | bash
• Download tarball and install

Continuous Integration

In situations where you want a consistent toolchain, between builds and build machines, we publish deb and rpm packages to apt.rust-lang.org and yum.rust-lang.org respectively. Be forewarned, these packages do not 100% conform to the philosophical requirements and installation conventions of Debian-based and EL-based distributions. If this is important to you, we recommend you use the older, distribution provided version of Rust.

To install from our package repositories:

• .deb and .rpm for installing our package repository
• sudo apt-get update
• sudo apt-get install rust

For situations where we do not have package support for your platform of choice, we do have release tarballs, though drop us a line. We're constantly evaluating cost/benefit for community expansion.