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).
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.
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
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.
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)> 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/ - 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.
And we do that too—for OpenBSD -current. But we have neither the manpower nor the interest to do such work for old releases.
* 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.
It's a small miracle things like Rust are supported on OpenBSD at all, let alone things outside of -current.
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.