4 ms·

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 becau

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
      > latest rustc always able to compile older rust code. That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.
      - vlovich123 2y ago
        I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.
        School-Cotton 2y ago
        It is correct. For example, this code (admittedly a contrived example, just to illustrate the point) compiles in 1.82 but not in 1.83: trait OptionExt { fn get_or_insert_default(); } impl<T> OptionExt for Option<T> { fn get_or_insert_default() {} } fn main() { Option::<()>::get_or_insert_default(); } The reason is that `get_or_insert_default` was added to the stdlib in 1.83, and takes a different number of arguments, so it clashes with the user-defined one here.
- pm215 2y ago
  It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we could throw all that cooperation away and say "tough, you need to use up-to-the-minute rust, if that's a problem for distro packagers we don't care". But we want to be a good citizen in the traditional distro packaging world, as we have been up til now. Not every open source project will want or need to cater to that, but I think for us it matters. That doesn't mean that we always do the thing that is simplest for distros (that would probably be "don't use Rust at all"); but it does mean that we take distro pain into account as a factor when we're weighing up tradeoffs about what we do.
  - vlovich123 2y ago
    To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the Debian maintainers to backport patches.
    - pm215 2y ago
      I think that trust would be somewhat misplaced -- QEMU has historically not made particularly timely security fixes either on mainline or on branches. To the extent that our stable-branch situation is better today than it was some years ago, that is entirely because the person who does the downstream Debian packaging stepped up to do a lot more backporting work and stable-branch maintenance and releases. (I'm very grateful for that effort -- I think it's good for the project to have those stable branch releases but I certainly don't have time myself to do that work.) As an upstream project, we really don't want to be in the business of making, providing and supporting binary releases. We just don't have the volunteer effort available and willing to do that work. It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams.

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
    > latest rustc always able to compile older rust code. That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.
    - vlovich123 2y ago
      I don't believe this is correct. I have not once seen a new method being added to stdlib that causes code to not compile. And ABI concerns are a non-issue since Rust is statically linked.
      - School-Cotton 2y ago
        It is correct. For example, this code (admittedly a contrived example, just to illustrate the point) compiles in 1.82 but not in 1.83: trait OptionExt { fn get_or_insert_default(); } impl<T> OptionExt for Option<T> { fn get_or_insert_default() {} } fn main() { Option::<()>::get_or_insert_default(); } The reason is that `get_or_insert_default` was added to the stdlib in 1.83, and takes a different number of arguments, so it clashes with the user-defined one here.
pm215 2y ago
It's not about our own CI -- we could easily use rustup as part of setting up the CI environment, and I think we might actually be doing exactly that at the moment. Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we could throw all that cooperation away and say "tough, you need to use up-to-the-minute rust, if that's a problem for distro packagers we don't care". But we want to be a good citizen in the traditional distro packaging world, as we have been up til now. Not every open source project will want or need to cater to that, but I think for us it matters. That doesn't mean that we always do the thing that is simplest for distros (that would probably be "don't use Rust at all"); but it does mean that we take distro pain into account as a factor when we're weighing up tradeoffs about what we do.
- vlovich123 2y ago
  To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the Debian maintainers to backport patches.
  - pm215 2y ago
    I think that trust would be somewhat misplaced -- QEMU has historically not made particularly timely security fixes either on mainline or on branches. To the extent that our stable-branch situation is better today than it was some years ago, that is entirely because the person who does the downstream Debian packaging stepped up to do a lot more backporting work and stable-branch maintenance and releases. (I'm very grateful for that effort -- I think it's good for the project to have those stable branch releases but I certainly don't have time myself to do that work.) As an upstream project, we really don't want to be in the business of making, providing and supporting binary releases. We just don't have the volunteer effort available and willing to do that work. It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams.