Hacker News Reader

Hacker News

Comment by dathinab | Hacker News Reader

Full thread

dathinab

So basically:

- Firefox is hard to package so they won't package it (on stable).

- OpenBSD-current users are not affected as firefox has already been committed.

- Firefox-ESR is still maintained.

> (thanks to cbindgen and rust dependencies) on the stable branch (as this would require testing all rust consumers)

Can someone explain what they mean with this? What have other non firefox rust consumers to do with firefox being packaged?

The best guess I have is that to package firefox they need to package cbindgen and rust. And if they package cbindgen and rust officially all packages using it would now need to be tested as now (potentially) all their dependencies have been packaged?? But this seems strange TBH.

EDIT: So I guess they still will package Firefox-ESR on stable? Which will have (or maybe already has) all that dependencies, too? So it's just about having to do that packaging less often?

View on HN

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

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

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.

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

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

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

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

Reply on news.ycombinator.com