4 ms·

>You can of course install from your package manager Debian 11 was released a couple weeks ago and the rustc it ships with is already so out of date (7 months

>You can of course install from your package manager Debian 11 was released a couple weeks ago and the rustc it ships with is already so out of date (7 months old, gasp!) software written for modern rust versions can't be compiled with it. And this isn't a Debian only problem.

Macha 5y ago
Is this a Rust only problem? Decided to pick the most well known Go project, kubernetes, and the Go version (1.15) included in Debian 11 is too old to build the first kubernetes project in my search results, kubernetes client as it requires go 1.16, released february. I've certainly had issues with e.g. the Python or Node version being too outdated on Ubuntu, RHEL, CentOS etc. And when that happens, it's a bigger problem, as it's a runtime dependency, not just a build time one. It's the risk you sign up for picking a fixed release distro. Consequently, if you're developing cutting edge software in those languages, you're probably running nvm, your favourite virtualenv wrapper (poetry, pipenv, pip-tools), or letting your IDE download a runtime for you. And yes, these tools are full of curl | bash or curl | python install instructions.
- hypothesis 5y ago
  It appears that 1.16 is available in testing as different package. Chance is high that you will be able to install it without much hassle, since they shipped current stable like a week or so ago. [1] https://packages.debian.org/bookworm/golang-1.16-go https://packages.debian.org/bookworm/golang-1.16-go
- superkuh 5y ago
  It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. Bash actually gets new, backwards incompatible, features pretty often too but you never have to run a bash script in a container or some third party interpreter. Bash devs simply care about having their software be able to run on setups more than a handful of months old.
  - steveklabnik 5y ago
    Our surveys show that most users use stable rust, with few using exclusively nightly. The issue here isn’t about backwards compatibility, it’s about forward compatibility.
    - Macha 5y ago
      Isn't this a matter of perspective? The older Rust compiler is not forwards compatible with the new project. The newer project is not backwards compatible with older Rust compilers
      - deleted 5y ago
        [deleted]
      - steveklabnik 5y ago
        Compatibility is a property of two releases, and it is usually discussed in the context of the API you provide to consumers. It's Rust that's providing APIs here, not the projects themselves. Either way, the parent is talking about Rust here, so that's the perspective being shown.
  - busterarm 5y ago
    > It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. And yet at the same time the people working this way are pushing their changes out in a way that affects the rest of the world looking for stable repeatable systems. There was a brief few weeks at the beginning of this year where pyca/cryptography had a hard dependency on a rust compiler being on the local system. pyca/cryptography is a dependency of a large number of important applications, notably Ansible. You're fucking up my automation if you're expecting me to `curl <website> | sh` in my build pipelines. pyca/cryptography's maintainers were completely not understanding of the situation and derided anyone who criticized them for it along with statements like "I refuse to work in C++." Zero concern from them about breaking the world for lots of people.
busterarm 5y ago
For those that say that it can't be done, most of Haskell's ecosystem updates frequently in Arch.
- genewitch 5y ago
  Also rust updates fine in gentoo, as I know from compiling Firefox, but mentioning Gentoo all the time as an alternative to Ubuntu got old in 2012, hah.
  - busterarm 5y ago
    Right, but the people most affected by this are most likely running RHEL or CentOS which doesn't even have a package.
    - Macha 5y ago
      EPEL does, however. Don't most RHEL/CentOS users enable this? The default CentOS repos don't even have software like nginx or Ansible, and I think it'd be hard to argue that these aren't "mature" But also, if you're using RHEL/CentOS, haven't you implicitly signed up to _not_ running the cutting edge software? You get what the vendor will support. That's the tradeoff you have chosen by picking such a distribution.
      - busterarm 5y ago
        > haven't you implicitly signed up to _not_ running the cutting edge software Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety. It's psychopathic behavior.
        Macha 5y ago
        > Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety. I don't understand your complaint here. It feels like you want to have your cake and eat it. You want nobody else to use anything too new to be packaged in enterprise Linux repositories, yet you want freedom to use the latest versions of these software, despite having perfectly usable versions for your era of software packaged in that enterprise distro. Rust is now an indirect dependency of ansible and you need to go outside the RHEL supported process to build the latest commit of ansible (or Firefox, or linkerd, or whatever) on your RHEL/CentOS 7 system. Or you could just use the RHEL supported version of ansible. The current RHEL version (RHEL 8) even has Rust packages, in the same repository and level of trust as such famously cutting edge software as nginx, node and dotnet.
JoshTriplett 5y ago
The Rust packaged in Debian works to build Debian packages; for that purpose, it's fine. For other Rust work, I'm hoping that at some point Debian packages rustup, which would let people use Debian's secure trust chain to bootstrap into rustup's secure trust chain.

Macha 5y ago

Is this a Rust only problem? Decided to pick the most well known Go project, kubernetes, and the Go version (1.15) included in Debian 11 is too old to build the first kubernetes project in my search results, kubernetes client as it requires go 1.16, released february. I've certainly had issues with e.g. the Python or Node version being too outdated on Ubuntu, RHEL, CentOS etc. And when that happens, it's a bigger problem, as it's a runtime dependency, not just a build time one. It's the risk you sign up for picking a fixed release distro. Consequently, if you're developing cutting edge software in those languages, you're probably running nvm, your favourite virtualenv wrapper (poetry, pipenv, pip-tools), or letting your IDE download a runtime for you. And yes, these tools are full of curl | bash or curl | python install instructions.

hypothesis 5y ago
It appears that 1.16 is available in testing as different package. Chance is high that you will be able to install it without much hassle, since they shipped current stable like a week or so ago. [1] https://packages.debian.org/bookworm/golang-1.16-go https://packages.debian.org/bookworm/golang-1.16-go
superkuh 5y ago
It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. Bash actually gets new, backwards incompatible, features pretty often too but you never have to run a bash script in a container or some third party interpreter. Bash devs simply care about having their software be able to run on setups more than a handful of months old.
- steveklabnik 5y ago
  Our surveys show that most users use stable rust, with few using exclusively nightly. The issue here isn’t about backwards compatibility, it’s about forward compatibility.
  - Macha 5y ago
    Isn't this a matter of perspective? The older Rust compiler is not forwards compatible with the new project. The newer project is not backwards compatible with older Rust compilers
    - deleted 5y ago
      [deleted]
    - steveklabnik 5y ago
      Compatibility is a property of two releases, and it is usually discussed in the context of the API you provide to consumers. It's Rust that's providing APIs here, not the projects themselves. Either way, the parent is talking about Rust here, so that's the perspective being shown.
- busterarm 5y ago
  > It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. And yet at the same time the people working this way are pushing their changes out in a way that affects the rest of the world looking for stable repeatable systems. There was a brief few weeks at the beginning of this year where pyca/cryptography had a hard dependency on a rust compiler being on the local system. pyca/cryptography is a dependency of a large number of important applications, notably Ansible. You're fucking up my automation if you're expecting me to `curl <website> | sh` in my build pipelines. pyca/cryptography's maintainers were completely not understanding of the situation and derided anyone who criticized them for it along with statements like "I refuse to work in C++." Zero concern from them about breaking the world for lots of people.

busterarm 5y ago

For those that say that it can't be done, most of Haskell's ecosystem updates frequently in Arch.

genewitch 5y ago
Also rust updates fine in gentoo, as I know from compiling Firefox, but mentioning Gentoo all the time as an alternative to Ubuntu got old in 2012, hah.
- busterarm 5y ago
  Right, but the people most affected by this are most likely running RHEL or CentOS which doesn't even have a package.
  - Macha 5y ago
    EPEL does, however. Don't most RHEL/CentOS users enable this? The default CentOS repos don't even have software like nginx or Ansible, and I think it'd be hard to argue that these aren't "mature" But also, if you're using RHEL/CentOS, haven't you implicitly signed up to _not_ running the cutting edge software? You get what the vendor will support. That's the tradeoff you have chosen by picking such a distribution.
    - busterarm 5y ago
      > haven't you implicitly signed up to _not_ running the cutting edge software Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety. It's psychopathic behavior.
      - Macha 5y ago
        > Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety. I don't understand your complaint here. It feels like you want to have your cake and eat it. You want nobody else to use anything too new to be packaged in enterprise Linux repositories, yet you want freedom to use the latest versions of these software, despite having perfectly usable versions for your era of software packaged in that enterprise distro. Rust is now an indirect dependency of ansible and you need to go outside the RHEL supported process to build the latest commit of ansible (or Firefox, or linkerd, or whatever) on your RHEL/CentOS 7 system. Or you could just use the RHEL supported version of ansible. The current RHEL version (RHEL 8) even has Rust packages, in the same repository and level of trust as such famously cutting edge software as nginx, node and dotnet.

JoshTriplett 5y ago

The Rust packaged in Debian works to build Debian packages; for that purpose, it's fine. For other Rust work, I'm hoping that at some point Debian packages rustup, which would let people use Debian's secure trust chain to bootstrap into rustup's secure trust chain.