Chris's Wiki :: blog/linux/UbuntuBuildingFirefox

Ubuntu, building current versions of Firefox, and snaps

July 10, 2020

Today on Twitter, I said:

Given that Ubuntu's ostensible logic for putting Chrome in a snap is 'it makes maintaining it easier', my cynical side expects Ubuntu to also do this with Firefox before too long (due to Firefox's need for steadily increasing versions of Rust).

(The context here is LWN's Linux Mint drops Ubuntu Snap packages, via. For 'Ubuntu', you can read 'Canonical', since Canonical is driving this.)

Ubuntu ships current versions of Firefox (at the moment Firefox 78) in Ubuntu LTS releases, which means that they must build current versions of Firefox on all supported Ubuntu LTS versions. Firefox is built partly with Rust (among other things), and new releases of Firefox often require relatively recent versions of Rust; for instance, right now Firefox Nightly (which will become Firefox 80 or 81) requires Rust 1.43.0 or better. Nor is Rust the only thing that Firefox has minimum version requirements for. Firefox 78, the current release, requires nasm 2.14 or better if you want to build the AV1 codecs, and I'm sure there are others I just haven't tripped over yet.

This is a problem for Ubuntu because Ubuntu famously doesn't like updating packages on Ubuntu LTS (or probably any Ubuntu release, but I only have experience with LTS releases). Today, the need to build current Firefox versions on old Ubuntu LTS releases means that Ubuntu 16.04 has been dragged up to Rust 1.41.0 (the same Rust version that's on 18.04 and 20.04). If current versions of Rust weren't required to build Firefox, Rust on 16.04 would probably be a lot like Go, where the default is version 1.6 (that's the golang package version) and the most recent available one is Go 1.10 (which actually dates from 2018, which is modern for an LTS release from 2016). When Firefox 80 or so is released and requires Rust 1.43.0 or better, Ubuntu will have to update Rust again on all of the still supported LTS versions, which will probably still include 16.04 at that point.

Canonical can't like this. At the same time, they have to ship Firefox and they have to keep it current, for security reasons. Shipping Firefox as a Snap would deal with both problems, because Canonical would no longer need to be able to build the current Firefox from source on every supported Ubuntu release (LTS and otherwise, but the oldest ones are generally LTS releases). Given that Canonical wants to shove everyone into Snaps in general, I rather expect that they're going to do this to Firefox sooner or later.

PS: I'm not looking forward to this, because Snaps don't work with NFS mounted home directories or in our environment in general. Ubuntu moving Firefox to a Snap would probably cause us to use the official Mozilla precompiled binaries in the short term, and push us more toward another Linux release in the longer term (probably Debian).

Comments on this page:

By Paul Tötterman at 2020-07-10 03:03:51:

Firefox is available as a flatpak: https://flathub.org/apps/details/org.mozilla.firefox , in case you like it better.

By Ruben Greg at 2020-07-10 07:05:30:

Is there any strong reason that you want to start with 20.04 LTS now amid COVID? Is it newer hardware support? Bionic LTS is supported till 2023 or may be even longer. Or why not move to CentOS now itself instead all the bandage and pain over snap - especially - https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004SnapsHomeIssue

By sapphirepaw at 2020-07-10 09:30:32:

Yeah, Canonical doesn't want to update anything if they don't have paying customers for it. The "no drawing tablets work" Qt bug, that was fixed in the next patch release upstream, was rejected for Lucid, which became a major factor in my returning to Windows and ending a dozen-year journey through FOSS desktops.

I wonder if Canonical should have chosen a different LTS timing. There wouldn't be so many in support at once if, say, LTS were every 3 years with 5 year support. Users couldn't skip over LTS versions, but they'd also have an extra year to do the upgrade. The only thing is, ESM with a 5-year extension pretty much eats away all of the gains of that model, and 3 years allows even more drift between the LTS versions.

There's no great answer between the pressures of "don't make changes" and "get shiny new toys," I guess.

By cks at 2020-07-10 10:14:15:

We have Ubuntu 16.04 machines that have to be migrated to 20.04 before next April ends normal 16.04 support, and in general we like user-facing machines to be on the latest Ubuntu LTS so that people get relatively current versions of programs (including things like Rust).

In general (and without Snaps), Ubuntu remains the best balance of package availability, relatively current packages, and relatively long term support for us. RHEL/CentOS releases are too infrequent and consequently the packages get too old. Debian comes close, which is one reason it's our obvious alternative, but its support period is somewhat uncertain.

By George at 2020-07-13 02:31:29:

If Ubuntu try to switch off to snap, i'll try to switch my Dell development edition (which was sold with ubuntu onboard) to Debian.

Is I'm paying customer? Doesn't matter, they don't do updates anyway.

Written on 10 July 2020.

«	Link: Mime type associations (on Linux)

The impact on middleware of expanding APIs with Go's interface smuggling