On Debian based (not Ubuntu) what is the package name to install Rust?

Not too sure if I should install cargo (sudo apt install cargo) or if there is another package I should install for Debian based?

I would recommend neither, but rather to use rustup.
Distribution packages (unless you're on a rolling distro) tend to be sorely outdated.


Thanks mate :slight_smile:

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, run:
source "$HOME/.cargo/env"

Any idea how to do the same on fish shell as I get this error message:

~/.cargo/env (line 4): 'case' builtin not inside of switch block
case ":${PATH}:" in
from sourcing file ~/.cargo/env
source: Error while reading file “/home/joe/.cargo/env”

I’m not familiar with fish, but search results on how to do it suggest this answer:

set -U fish_user_paths $HOME/.cargo/bin $fish_user_paths

Or alternatively this approach, pointed out in a later reply:


For fish 3.2.0 or upper, released in March 2021, the easiest way to add rust to path permanently is like that:

fish_add_path $HOME/.cargo/bin

It will automatically append the specified folder to fish_user_paths in $HOME/.config/fish/fish_variables.
Documentation can be found here: fish_add_path - add to the path — fish-shell 3.5.1 documentation

I hope it helps

1 Like

Thanks that works,

but one thing, when I ran ls -l | grep cargo inside $HOME/.cargo/bin it didn't find cargo so how is cargo even added to my shell?

For me, it’s in there. Does executing cargo work for you though? If yes, you can see probably the location by executing which cargo.

nope until I sourced it though.

I’m not quite understanding what your situation is. Does cargo work for you or not? Does executing rustup work or not? Did the installation claim to have been successfull? If $HOME/.cargo/bin doesn’t contain cargo, what does it contain though?

Yes all of these work. I think I might have been in the wrong directory, nevermind. I can see cargo exist.

1 Like

It would be nice to be able to just do a

sudo apt update
sudo apt upgrade

and then everything is at the latest version. Think what would happen if each piece of software came with its own install and update tool.
Some providers set up their own repository, so that users can set up apt to pull the latest version from there. Wouldn't it be nice to have that for Rust, too?

Maybe, but as long as distros make it impossible to plug your own package format into the apt upgrade process this remains a pipe dream.

We would have precisely and exactly what we have now? Out of significant, popular, languages only C/C++ don't offer a native way to easily download and install packages.

Partially because C/C++ development started in an era before Internet-based repositories, partially because people still can not decide whether conan or vcpkg, partically because everyone have their own, favorite, solution and partially, yes, because C/C++ developers already do all the painful contortions needed to support distro-makers, may as well benefit from these.

Tell me how to use these on Windows (development platform #1) and MacOS (development platform #2), then we can compare to Rustup approach.

The Debian stability is by design. Part of what they offer is things are the same and stay that way for a while.

The rust packages on Debian are mostly for making Debian specific rust packages. Their wiki does suggest using 'rustup' for most uses.



Ah yes, there are two parts to this.
If you want to distribute Rust tooling (rustc, cargo, rustfmt ...) etc via a package manager, it is very possible and works really well already on most distros. The trouble will be that different distros provide differently outdated versions. If you are on something Arch-based, you would almost always be able to do sudo pacman -S rust and get the latest version. On Debian, I would imagine you can do the same, but then you would get very outdated versions of Rust. If you are okay with that, then you can do it. Otherwise, rustup is the way to go.
On the other hand, it is not possible to distribute Rust crates at all via package managers, mostly because of ABI instability.

The word latest is very relative. What is latest for Debian is old for Ubuntu, outdated for Fedora and ancient history for Arch. Different distros have different philosophies and unfortunately nothing much can be done about that.

1 Like

The only solution is to push more work on crates maintainers, but what worked with C++ doesn't work with Rust.

In C++ world you can use libraries together which were released at different times. Often released 2, 3, 5 years apart.

This works but only because typical C or C++ library includes more “impedance mismatch compensation” code than typical Rust crate includes code in total!

This approach works great for the distros but doesn't work all that well for developers. Even in C++ world large “complexes” are released together and you are not supposed to “mix and match” (.e.g all GNOME libraries, all KDE libraries, and so on).

That was strict necessity half-century ago when C was established because that's the only way to distribute things on tapes (like early versions of GNU were distributed) or stamped CDs (all these old software collections: SimTel, Walnut Creek, etc).

Today this makes no sense whatsoever: why do I, as developer, may want to spend my time doing crazy dance just to ensure that various distributions may pick and match various crates in a fashion they want?

They need this ability, they can do the work. If they can.

For Rust developer tools, no need to push them into distro repos, just set up your own repo and let users point their apt to it.

For Rust/Cargo development tools specifically, cargo-quickinstall also offers a mini distro for precompiled development tools, and cargo-binstall will fetch binary artifacts straight from the repo's releases or the quickinstall repository. Managing version updates through apt (or brew or winget or...) can certainly be more convenient to have everything in one location, but cargo-binstall is wonderful for a lightweight solution for freestanding development tooling.

FWIW, this presentation from some years ago by one of the OpenSUSE maintainers does a pretty good job at articulating the issues around distribution package managers and language-centric package managers (and how ultimately the overlaps between them are a result of conflating multiple goals).

It appears the personal conclusion they reach is that doing everything in distribution package managers is actually not a good idea. And some application and image managers like snap and flatpak are mentioned as examples of attempts to solve some of the problems with traditional package managers that come with Linux distros.


The biggest problem with distributions lie with the fact that they solve precisely two problems which no longer exist:

  1. When storage is limited then it's not possible to install useful set of packages as one set, you need something to mix-and-match bits and pieces.
  2. When delivery mechanism (tapes, floppies, CD-ROMs) introduces latencies measured in weeks and months you need to test and stabilize collection of packages you offer.

Later, since distributions were already there their power was abused to provide additional facilities. But with primary reason for their existence disappearing they very much turned into a solution in a search of a problem.

That's what systemd tried to solve and what other projects (snap, flatpak, etc) are trying to solve, but, ultimately, it's hard because distributions are, kind of, already there, and they do solve lots of problems thus attempts to offer better solutions don't have much incentive.

1 Like

Except problems clearly still exist and even Rust applications are lambasted as "unpackageable" by the very people working on these problems. Packaging Rust for Fedora [LWN.net]

I don't see "do nothing" as a viable strategy.

1 Like