Hacker News Reader

Comment by anjbe | Hacker News Reader

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.

View on HN

> 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

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.

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)

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.

> 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/ - 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.

> 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.

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.

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.

Reply on news.ycombinator.com