3 ms·

It appears that they are unwilling to update to the latest Rust-stable release due to the testing burden on the OpenBSD-stable team; which then conflicts with t

It appears that they are unwilling to update to the latest Rust-stable release due to the testing burden on the OpenBSD-stable team; which then conflicts with the Firefox Rust update policy of, as I read it, ‘latest Firefox stable will use latest Rust stable’. https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox

dathinab 7y ago
Ok thanks, I guess this is somewhat understandable. Through I wonder a bit why they don't automate the tests (maybe the computation cost?). (E.g. rust automatically runs the tests of all libraries/programs published on crates.io to find regressions, through that takes a day or so to complete).
- anjbe 7y ago
  Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. Now what? Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? And all this to only get automated tests passing. Any regressions in behavior not tested are not noticed (or more likely, noticed by users much later, requiring further investigation at that point in time to narrow down the Rust backport as the cause). In the meantime, this packager’s work on other OpenBSD packages in -current (what most OpenBSD developers actually use day‐to‐day) completely stops. That’s some insight into the mindset of a software packager. Non‐security backports to language runtimes are a serious maintenance burden.
  - floatingatoll 7y ago
    > Now what? Discard the outdated assumption that a single installed dependency version is sufficient for all packages, and then improve the packaging system to permit multiple releases of Rust, Python, etc. to coexist as dependencies so that packages can migrate gradually over time rather than forcibly whenever one crosses the line. Homebrew does a fine job of this. Installing python@2 doesn’t necessarily mean it’ll be made “the default”, but it does make it available for dependencies without interfering with the default python 3 package. EDIT: NixOS does this right: https://news.ycombinator.com/item?id=22023086 https://news.ycombinator.com/item?id=22023086
    - int_19h 7y ago
      Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. NixOS changes a lot of things to make it all work. If you're willing to pay that tax for the sake of package management, great! People who use BSDs generally aren't.
      - inferiorhuman 7y ago
        Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. Rust is designed to support multiple toolchains with rustup. I've got the following installed on my desktop box: stable-x86_64-apple-darwin nightly-2018-12-14-x86_64-apple-darwin nightly-arm-unknown-linux-gnueabihf nightly-x86_64-apple-darwin (default)
        int_19h 7y ago
        If I remember correctly, the granularity for this mechanism is pretty much arbitrary - i.e. you can have 1.2.3 and 1.2.4 installed side by side if you wanted to. From a practical perspective, if this means that the apps can start depending on 1.2.3 specifically, it requires the distro to package every minor version separately, which is very time- and space-consuming. With gcc and clang it's easier, because usually only the major versions get packaged side by side, and minor versions are simple upgrades.
  - zozbot234 7y ago
    > Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. > Now what? > Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? Yes, people do exactly that. It's part of running a "rolling" distro, see e.g. the Debian Testing transition tracker at https://release.debian.org/transitions/ https://release.debian.org/transitions/ - These transitions are running essentially all the time; they're only "put on hold" as a first step in the process of making a new stable release. And even then, newer versions of packages such as rust can still enter stable as part of an "unrelated" security update.
    - anjbe 7y ago
      > Yes, people do exactly that. It's part of running a "rolling" distro And we do that too—for OpenBSD -current. But we have neither the manpower nor the interest to do such work for old releases.
      - fluffything 7y ago
        There are many options to solve that: * switch to a shorter stable release cycle (4 weeks, 6 weeks, etc.) with dynamic releases (e.g. if a zero day happens, fix current, and do a new stable release) * switch to only supporting -current * switch to something like Nix to allow stable users to "switch" some packages from stable to current, without having to bump their whole system (this would have allowed stable users to update their Firefox-stable to Firefox-current) A good packaging process should not assume that downstream packages can be trusted to have meaningful processes. Relying on Firefox having -esr releases is a temporary workaround.
    - lllr_finger 7y ago
      The OpenBSD port for Rust 1.39 - the long awaited async/await release - wasn't available for several (6?) weeks. The reason for this was the maintainer is a single person with a complex setup, trying to wrestle with LLVM issues and more esoteric things like Sparc64 support. It's a small miracle things like Rust are supported on OpenBSD at all, let alone things outside of -current.
compuguy 7y ago
They will still have to update rust when the next major version of Firefox ESR is pushed out this June/July...
- anjbe 7y ago
  OpenBSD has a six‐month release cycle; Firefox-ESR backports will be able to use whatever version of Rust is in 6.7-stable (release coming this May).
  - floatingatoll 7y ago
    > We expect esr releases will stay on the same minimum Rust version, so backporting security fixes may require Rust compatibility work too. The policy suggests that ESR will update infrequently to the latest Rust-stable at each major .0 release, so as long as 6.7-stable and ESR end up having the same Rust stable version, that will work out. That’s a coincidence-based success, not a certain one, though.

dathinab 7y ago

Ok thanks, I guess this is somewhat understandable. Through I wonder a bit why they don't automate the tests (maybe the computation cost?). (E.g. rust automatically runs the tests of all libraries/programs published on crates.io to find regressions, through that takes a day or so to complete).

anjbe 7y ago
Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. Now what? Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? And all this to only get automated tests passing. Any regressions in behavior not tested are not noticed (or more likely, noticed by users much later, requiring further investigation at that point in time to narrow down the Rust backport as the cause). In the meantime, this packager’s work on other OpenBSD packages in -current (what most OpenBSD developers actually use day‐to‐day) completely stops. That’s some insight into the mindset of a software packager. Non‐security backports to language runtimes are a serious maintenance burden.
- floatingatoll 7y ago
  > Now what? Discard the outdated assumption that a single installed dependency version is sufficient for all packages, and then improve the packaging system to permit multiple releases of Rust, Python, etc. to coexist as dependencies so that packages can migrate gradually over time rather than forcibly whenever one crosses the line. Homebrew does a fine job of this. Installing python@2 doesn’t necessarily mean it’ll be made “the default”, but it does make it available for dependencies without interfering with the default python 3 package. EDIT: NixOS does this right: https://news.ycombinator.com/item?id=22023086 https://news.ycombinator.com/item?id=22023086
  - int_19h 7y ago
    Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. NixOS changes a lot of things to make it all work. If you're willing to pay that tax for the sake of package management, great! People who use BSDs generally aren't.
    - inferiorhuman 7y ago
      Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. Rust is designed to support multiple toolchains with rustup. I've got the following installed on my desktop box: stable-x86_64-apple-darwin nightly-2018-12-14-x86_64-apple-darwin nightly-arm-unknown-linux-gnueabihf nightly-x86_64-apple-darwin (default)
      - int_19h 7y ago
        If I remember correctly, the granularity for this mechanism is pretty much arbitrary - i.e. you can have 1.2.3 and 1.2.4 installed side by side if you wanted to. From a practical perspective, if this means that the apps can start depending on 1.2.3 specifically, it requires the distro to package every minor version separately, which is very time- and space-consuming. With gcc and clang it's easier, because usually only the major versions get packaged side by side, and minor versions are simple upgrades.
- zozbot234 7y ago
  > Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. > Now what? > Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? Yes, people do exactly that. It's part of running a "rolling" distro, see e.g. the Debian Testing transition tracker at https://release.debian.org/transitions/ https://release.debian.org/transitions/ - These transitions are running essentially all the time; they're only "put on hold" as a first step in the process of making a new stable release. And even then, newer versions of packages such as rust can still enter stable as part of an "unrelated" security update.
  - anjbe 7y ago
    > Yes, people do exactly that. It's part of running a "rolling" distro And we do that too—for OpenBSD -current. But we have neither the manpower nor the interest to do such work for old releases.
    - fluffything 7y ago
      There are many options to solve that: * switch to a shorter stable release cycle (4 weeks, 6 weeks, etc.) with dynamic releases (e.g. if a zero day happens, fix current, and do a new stable release) * switch to only supporting -current * switch to something like Nix to allow stable users to "switch" some packages from stable to current, without having to bump their whole system (this would have allowed stable users to update their Firefox-stable to Firefox-current) A good packaging process should not assume that downstream packages can be trusted to have meaningful processes. Relying on Firefox having -esr releases is a temporary workaround.
  - lllr_finger 7y ago
    The OpenBSD port for Rust 1.39 - the long awaited async/await release - wasn't available for several (6?) weeks. The reason for this was the maintainer is a single person with a complex setup, trying to wrestle with LLVM issues and more esoteric things like Sparc64 support. It's a small miracle things like Rust are supported on OpenBSD at all, let alone things outside of -current.

compuguy 7y ago

They will still have to update rust when the next major version of Firefox ESR is pushed out this June/July...

anjbe 7y ago
OpenBSD has a six‐month release cycle; Firefox-ESR backports will be able to use whatever version of Rust is in 6.7-stable (release coming this May).
- floatingatoll 7y ago
  > We expect esr releases will stay on the same minimum Rust version, so backporting security fixes may require Rust compatibility work too. The policy suggests that ESR will update infrequently to the latest Rust-stable at each major .0 release, so as long as 6.7-stable and ESR end up having the same Rust stable version, that will work out. That’s a coincidence-based success, not a certain one, though.