5 ms·

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several ye

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

deleted 2y ago
[deleted]
tangent128 2y ago
Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down. So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories. (Not just rustup- Debian requires repackaging Cargo dependencies so that the build can be conducted offline entirely from source packages.)
- vlovich123 2y ago
  You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo that makes the latest tool chain available on older Debian platforms. As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. The current policy Debian is holding is really difficult to work with and causes downstream projects to do all sorts of workarounds to make Debian builds work (not just for Rust by the way - this applies to C++ as well). And it’s not like this is something it’s unfamiliar with - you can install multiple JVM versions in parallel and choose a different default.
  - ronsor 2y ago
    > As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. Most toolchains don't have as much churn as Rust.
    - vlovich123 2y ago
      Disagree. No stable release of Debian today supports c++23 which is coming up on two years old at this point (this corresponds to a major Rust edition, not the minor stuff they publish on an ongoing basis every month). Java in Bookworm installs JDK 17 which is three years old at this point. Java itself is on 23 with 21 being an LTS release. This means that upstream users intentionally maintain an old toolchain just to support Debian packaging or maintain their own deb repo with newer tools. You’re confusing cause and effect. People aren’t migrating because Debian packaging lags so badly, not because there aren’t improvements projects would love to otherwise use.
    - 0x457 2y ago
      > Most toolchains don't have as much churn as Rust. What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code. Now compare rust releases to this: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
      - vlovich123 2y ago
        Rust’s release cadence is 6 weeks not 6 months.
        0x457 2y ago
        My bad, I thought it was 6 months. Okay, a bit too often, but no reason why debian folk can't update it more often than it is now.
      - School-Cotton 2y ago
0x457 2y ago
Because QEMU wants their thing to be packaged in various distros. Those distros don't allow packages to bring their own tool chain (for good reasons).
- vlovich123 2y ago
  My point is there should be a discussion about how to make newer toolchains available to end users. This has nothing to do about packaging within the distro and a non-issue since whatever "tip of tree" is for QEMU is what would get frozen as the "blessed" version and that could use whatever tip for the toolchain they needed since that's likely the same version that Debian would freeze.
capitainenemo 2y ago
Well, at least a couple of years ago, one surprising thing I discovered with rustup was that unlike distros that have a clean install/uninstall, rustup was rm -rf * ing everything in the place it was installed. There was an open bug on it and multiple complaints. I, who needed it for various system builds, had innocently rustup'd to /usr/local. On uninstall, it wiped all of /usr/local. I had backups on that machine, but it was still an unpleasant experience and I did lose a few not-too-important scripts. I don't know if others have run into the same thing, but it's why I'd trust Gentoo's packaging more.
jeroenhd 2y ago
The goal of non-rolling release distros is to have a predefined set of dependencies, which the distro maintains and fixes if necessary. If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture, Debian must fix that for their users. That leaves the curl2bash installers that are popular with fast moving tools and languages useless for long term stability. The same goes for crates, which can be pulled at any time for almost any reason and break compiles. Then there are other setups distros can choose to support, like having update servers/package repositories for updating servers that aren't allowed to connect to the internet or are even air gapped. You can't save rustup to a DVD, but you can take a copy of the Debian repository and update air gapped servers in a way that leaves a permanent trace (as long as you archive the disks). Not all distros have this problem. In theory the Rust people could set up an apt/repository Debian users can add to get the best features of a package manager and the latest version, and distros like Arch/Gentoo don't bother with the stability guarantees most distros have. Qemu can ignore these requirements and opt into not being packaged into distros like Debian or Ubuntu or Fedora or RHEL or Oracle Linux. That'd cost them a lot of contributions from those platforms, though, and may cause a risk of the project being forked (or even worse, end up in the ffmpeg/avconv situation).
- vlovich123 2y ago
  > If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture Then you stop publishing new versions of the toolchain for x86 releases of the distro? I fail to see the problem. Nothing prevents you from not making a newer version of the toolchain available. Indeed, that's the default. > The same goes for crates, which can be pulled at any time for almost any reason and break compiles. I never said you have to extend this by making all versions of crates available. You can freeze the crates using the same mechanism to redirect Cargo as they do today. I'm going to ignore the rustup stuff as I wasn't proposing rustup be used for building the base Debian image itself - that was a comment more about the environment QEMU itself can advocate for for people building it & leaving it to the distros to solve their own packaging problems.
uecker 2y ago
I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.
- vlovich123 2y ago
  With cert pinning, CT, and other advancements in transport security, I don't see a huge fundamental difference between this and adding a random apt repository & doing an apt install.
  - uecker 2y ago
    You should also not add random apt repositories from the internet. But there is still a major different in terms of the implications for user education.
- School-Cotton 2y ago
  Why is downloading a shell script from a website and running it any less safe than downloading a package from a distro repository and running it? The owners of rustup.rs are just as unlikely to be malicious as the people who package things for Debian.
  - uecker 2y ago
    Adding a package repository is a very conscious choice that also requires a password. Cut & pasting a line of code from we website is not. This is why a lot of time and effort was spend in the past educating users not to run random code from the internet. That is may be safe in this particular specific case does not change the fact that this generally undermines the message that one should not cut&paste arbitrary code from a website into a terminal.
- keybored 2y ago
  Read what the “safe” means. It is narrow. Memory safety.

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

deleted 2y ago

[deleted]

tangent128 2y ago

Rustup downloads toolchains from third-party (to the distro) repositories; distros do not want to be in a position where they can no longer build packages because of an external service going down. So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories. (Not just rustup- Debian requires repackaging Cargo dependencies so that the build can be conducted offline entirely from source packages.)

vlovich123 2y ago
You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo that makes the latest tool chain available on older Debian platforms. As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. The current policy Debian is holding is really difficult to work with and causes downstream projects to do all sorts of workarounds to make Debian builds work (not just for Rust by the way - this applies to C++ as well). And it’s not like this is something it’s unfamiliar with - you can install multiple JVM versions in parallel and choose a different default.
- ronsor 2y ago
  > As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. Most toolchains don't have as much churn as Rust.
  - vlovich123 2y ago
    Disagree. No stable release of Debian today supports c++23 which is coming up on two years old at this point (this corresponds to a major Rust edition, not the minor stuff they publish on an ongoing basis every month). Java in Bookworm installs JDK 17 which is three years old at this point. Java itself is on 23 with 21 being an LTS release. This means that upstream users intentionally maintain an old toolchain just to support Debian packaging or maintain their own deb repo with newer tools. You’re confusing cause and effect. People aren’t migrating because Debian packaging lags so badly, not because there aren’t improvements projects would love to otherwise use.
  - 0x457 2y ago
    > Most toolchains don't have as much churn as Rust. What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code. Now compare rust releases to this: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
    - vlovich123 2y ago
      Rust’s release cadence is 6 weeks not 6 months.
      - 0x457 2y ago
        My bad, I thought it was 6 months. Okay, a bit too often, but no reason why debian folk can't update it more often than it is now.
    - School-Cotton 2y ago

0x457 2y ago

Because QEMU wants their thing to be packaged in various distros. Those distros don't allow packages to bring their own tool chain (for good reasons).

vlovich123 2y ago
My point is there should be a discussion about how to make newer toolchains available to end users. This has nothing to do about packaging within the distro and a non-issue since whatever "tip of tree" is for QEMU is what would get frozen as the "blessed" version and that could use whatever tip for the toolchain they needed since that's likely the same version that Debian would freeze.

capitainenemo 2y ago

Well, at least a couple of years ago, one surprising thing I discovered with rustup was that unlike distros that have a clean install/uninstall, rustup was rm -rf * ing everything in the place it was installed. There was an open bug on it and multiple complaints. I, who needed it for various system builds, had innocently rustup'd to /usr/local. On uninstall, it wiped all of /usr/local. I had backups on that machine, but it was still an unpleasant experience and I did lose a few not-too-important scripts. I don't know if others have run into the same thing, but it's why I'd trust Gentoo's packaging more.

jeroenhd 2y ago

The goal of non-rolling release distros is to have a predefined set of dependencies, which the distro maintains and fixes if necessary. If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture, Debian must fix that for their users. That leaves the curl2bash installers that are popular with fast moving tools and languages useless for long term stability. The same goes for crates, which can be pulled at any time for almost any reason and break compiles. Then there are other setups distros can choose to support, like having update servers/package repositories for updating servers that aren't allowed to connect to the internet or are even air gapped. You can't save rustup to a DVD, but you can take a copy of the Debian repository and update air gapped servers in a way that leaves a permanent trace (as long as you archive the disks). Not all distros have this problem. In theory the Rust people could set up an apt/repository Debian users can add to get the best features of a package manager and the latest version, and distros like Arch/Gentoo don't bother with the stability guarantees most distros have. Qemu can ignore these requirements and opt into not being packaged into distros like Debian or Ubuntu or Fedora or RHEL or Oracle Linux. That'd cost them a lot of contributions from those platforms, though, and may cause a risk of the project being forked (or even worse, end up in the ffmpeg/avconv situation).

vlovich123 2y ago
> If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture Then you stop publishing new versions of the toolchain for x86 releases of the distro? I fail to see the problem. Nothing prevents you from not making a newer version of the toolchain available. Indeed, that's the default. > The same goes for crates, which can be pulled at any time for almost any reason and break compiles. I never said you have to extend this by making all versions of crates available. You can freeze the crates using the same mechanism to redirect Cargo as they do today. I'm going to ignore the rustup stuff as I wasn't proposing rustup be used for building the base Debian image itself - that was a comment more about the environment QEMU itself can advocate for for people building it & leaving it to the distros to solve their own packaging problems.

uecker 2y ago

I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.

vlovich123 2y ago
With cert pinning, CT, and other advancements in transport security, I don't see a huge fundamental difference between this and adding a random apt repository & doing an apt install.
- uecker 2y ago
  You should also not add random apt repositories from the internet. But there is still a major different in terms of the implications for user education.
School-Cotton 2y ago
Why is downloading a shell script from a website and running it any less safe than downloading a package from a distro repository and running it? The owners of rustup.rs are just as unlikely to be malicious as the people who package things for Debian.
- uecker 2y ago
  Adding a package repository is a very conscious choice that also requires a password. Cut & pasting a line of code from we website is not. This is why a lot of time and effort was spend in the past educating users not to run random code from the internet. That is may be safe in this particular specific case does not change the fact that this generally undermines the message that one should not cut&paste arbitrary code from a website into a terminal.
keybored 2y ago
Read what the “safe” means. It is narrow. Memory safety.