1799516 - (firefox-deb-repackage) [meta] Ship Firefox Linux releases in deb packages

Status: REOPENED

(Release Engineering :: Release Automation, enhancement)

Description

[Gabriel Bustamante [:gabriel]]

There is no Mozilla repository (or deb packages) for people to update and install Firefox via APT on Debian, Ubuntu, and derivatives.

Comment 1

[Jon Buckley [:jbuck]]

I guess two questions here: Should we host our debian repository out of archive.mozilla.org, or another sub-domain? And should we manage it ourselves, or use a managed service like Artifact Registry?

My understanding is that Artifact Registry doesn't support custom domains, so that might force our decision for us? Or we'd need to put something in front of Artifact Registry. Probably also good to look at bandwidth costs for Artifact Registry vs our own load balancers.

Comment 2

[chris valaas [:cvalaas]]

For future reference: jbuck found https://cloud.google.com/blog/topics/developers-practitioners/hack-your-own-custom-domains-container-registry which implies we can just put a reverse proxy (and CDN) in front of artifact registry and serve it the same way we do the rest of productdelivery

Comment 3

[Hal Wine [:hwine] use NI!]

The layout on archive.m.o has an impact on other processes and standing practices. The official version should be stored in the normal release build hierarchy.

Reminder: A user accessible package repository is a new service, and an RRA needs to be done prior to any go-live. That can also address the domain question.

Comment 4

[Gabriel Bustamante [:gabriel]]

Attachment: Bug 1799516 - Update firefox bin link to match the name of the .deb package r?jlorenzo,#releng-reviewers

Depends on D167729

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2678385eb9b2
Update firefox bin link to match the name of the .deb package r=releng-reviewers,jlorenzo

Comment 6

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/2678385eb9b2

Comment 7

[Johan Lorenzo [:jlorenzo]]

Reopening bug for being a meta one.

Comment 8

[Gabriel Bustamante [:gabriel]]

That's my bad, I cloned one of the beetmover bugs here to file a different one and forgot to delete the "blocks" section 🤦‍♂️

Comment 9

[Gabriel Bustamante [:gabriel]]

I linked Bug 1772219 because this might impact users of the Firefox .deb packages when they run apt-get upgrade

Comment 10

[Darkspirit]

What does Chrome differently or does it also suffer from bug 1705217, etc?

Comment 11

[Robin Steuber (she/her) [:bytesized]]

(In reply to Darkspirit from comment #10)

1. What does Chrome differently or does it also suffer from bug 1705217, etc?

They use a fork server that they call the zygote process to launch new processes from in-memory data rather than relying on the files on disk. See this page for more details.

Comment 12

[Gabriel Bustamante [:gabriel]]

(In reply to Robin Steuber (they/them) [:bytesized] from comment #11)

(In reply to Darkspirit from comment #10)

1. What does Chrome differently or does it also suffer from bug 1705217, etc?

They use a fork server that they call the zygote process to launch new processes from in-memory data rather than relying on the files on disk. See this page for more details.

I am getting the feeling that the Nightly .deb builds might not be viable without fixing this.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Johan, can you please clarify what's needed from a relnote perspective here?

Comment 14

[Johan Lorenzo [:jlorenzo]]

I'm no expert in release notes. I was thinking of something like:

New: Mozilla's new .deb package for Debian, Ubuntu, and Linux Mint users. See these instructions[add link].

Would an entry like this make sense?

Comment 15

[Andrew Aitchison]

I see that this is now public in
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions
but https://bugzilla.mozilla.org/show_bug.cgi?id=1867758 and https://bugzilla.mozilla.org/show_bug.cgi?id=1752638 are not fixed in 126.0.1

Comment 17

[Jérôme]

I performed an other test on an actual host :

cpu Intel Core i5-2520M
os Xubuntu 21.10 (impish)
hard disk model ST9250320AS (5400 r/mn choosen because less noise)
desktop : XFCE
preload isn't installed

I installed one of the following flavours of Firefox at a time (I ensured the other flavour was desinstalled) :

either the snap package for version 101.0-2
or the deb package (from ubuntu repository) for version 100.0.2.

Before starting the test of a flavour, I started it for the first time and I made the new page empty (no web search, no shortcut or recent activity).

Below is the test :

The host is up to date from the day (snap refresh, apt update), I restart the computer.
I login into the guest desktop environment.
I wait for roughly 60 s (stopwatch in hand).
I launch Firefox by the desktop menu entry and measure the start-up duration until the window appears.
I close Firefox and wait roughly 30s (stopwatch in hand).
I launch Firefox again and measure.
I close Firefox and wait roughly 30s (stopwatch in hand).
I launch Firefox again and measure.

In case of the deb package application :
4. gives 21 s
6. gives 3 s
8. gives 3 s

In the case of the snap package application :
4. gives 27 s
6. gives 4 s
8. gives 4 s

As a conclusion for this specific hardware and those software versions, the snap flavour is roughly 30% slower than deb package in both cold or warm start-up.

Comment 18

[Jérôme]

There is a last reason for providing a deb package. On Ubuntu 22.04 I don't need the snap except for Firefox . However, the snap system slows down the startup of Ubuntu 22.04.

Comment 19

[Jérôme]

I'm describing below an other test with the same physical host and virtual guest.
I installed the xfce desktop environment (via tasksel) and I uninstalled all lxqt packages. I disabled the snap user service start (from the xfce session configuration panel).
Then, the cold start of the deb package application is down in less than 2 seconds (better). Maybe de xfce desktop environment already loaded a few libraries (libgtk-3-0, ...).
In addition, I measured the used memory (free -k) by comparing the "used" memory field before launch and a few seconds after the window appeared.
With deb package application : 266 MB.
With snap package application : 397 MB (+49%).
It seems the deb package application saves memory because it is sharing the libraries with the other applications of the desktop.
Note that I didn't count the used memory by the snap machinery (in case you wouldn't install snapd with a deb package application).

Comment 20

[Jérôme]

(In reply to Jérôme from comment #19)

I'm describing below an other test with the same physical host and virtual guest.
Host : a Debian host.
Guest : Debian bookworm x86_64, LXQT, deinstalled preload and firefox-esr for light desktop.
On the guest I installed 2 flavours of the same 100.0 version of Firefox on :

• the snap : 100.0-2 (snap revision 1300) with the other required snaps (gnome-3-38-2004 0+git.1f9014a rev 99, gtk-common-themes 0.1-59-g7bca6ae rev 1519, core20 20220329 rev 1434)
• the deb package by hand from sid repository : 100.0-1.