Hello.
Hi, everyone.
My name is Gabriel.
I'm a senior release engineer in Mozilla, and I work on
shipping Firefox on several different platforms.
And today I'm here to talk to you guys about the new debt
package that we are shipping to our Mozilla app repository.
So first I'm going to talk a little bit about the journey
from Nile to stable builds, and then I'm going to
elaborate on some of the reasons why we thought a native
package might be useful for people on debt-based distributions.
Okay.
So early last year we started talking about setting up
an app repository for Mozilla product builds to help us
offer better support on Linux and stuff like that.
It's really challenging to support distribution builds
for us because they're built with different compiler,
compiler versions.
We can lead to some issues.
Yeah, so first around October we started shipping a Nile package.
And it was mostly for Nile community.
This offered them some benefits like they didn't have to create
a desktop file.
It also made it easier to update the binary.
We have some data that actually suggests that we keep
people more up to date on these debt packages.
I think probably because people update the whole system
components in the app store or...
Yeah, I wonder if they did other stuff.
Yeah, so I made a blog post about that.
We got a lot of feedback from the community about
developer addition debt package.
So we shipped that.
And now as a Firefox 122 we're shipping stable builds
to the repository.
So we want you to be able to use Firefox how you want.
And we know browsers are complex applications that support
many different use cases in people's lives.
So we wanted to offer a native package in addition to
SNAP, some flat packs.
So this package, it's built in Mozilla infrastructure
from the Firefox source code without any modification.
And the builds are supported by Mozilla directly.
Another good thing about the package is that we spend a lot
of resources in optimizing the builds using PGO and things
like that.
And we wanted people to be able to get those benefits without
having to install our tar balls but rather getting packages
from this repository.
I like this one.
The updates are faster in case of chem spills.
So the new app repository is plugged in directly to the
Firefox release automation.
So when we ship Firefox we upload the build directly
to this repository as soon as it's available.
Which is nice in case of security patches and things like that.
And here's a slide about how to install it.
So you can visit that.
The website right there and follow instructions,
as I said.
It's easy.
It's just about adding the Mozilla app repository and
installing the package.
The package is not perfect, surprise.
So if you have feedback, if you actually try it out,
you can join our matrix channel and let us know if the package
is working for you, if you're having issues.
And Mozilla will offer support.
Thank you.
Thank you.
Thank you.
Thank you.
Yes.
Can you provide arm 64 builds?
Not yet.
Can you reply the question?
Yeah.
So here's if we offer arm 64 builds.
Not yet.
We've been talking about it.
Yeah.
Working on it.
How are the bindries constructed for these packages?
Do you use the native devian tooling to build it?
Or do you basically repackage the same binders you would put
in a snap file?
It's the same binary that we've been shipping as a tarble
forever.
And yeah, we use the native devian tooling to repackage that
into a dev package.
And that's what we put in the app repository.
I saw a hand over here.
I lost the person.
Someone had a question.
I don't have any questions.
Oh, OK.
You're tricking me now.
Yes, I see.
Coming.
For those new in the room, this is a challenge for me to have
10K today.
So don't hesitate to ask questions.
Hello.
Do you envision the dev package being like a stepping stone
towards the future where flat packs and snaps work well?
Or it will be like a permanent offering going forward?
I envision it as a permanent offering, just like an additional
option for people that like the packages.
Yeah, makes sense.
Why did you specifically choose dev as a packaging format?
I didn't quite understand that.
Over like something like flat pack and have a custom repository
for that.
Yeah, we already have a flat pack.
So this is just a different option for people that want to use
that packages.
There's already a Mozilla flat pack repository?
Yep.
OK, I didn't know that.
Good to know.
Yes, go ahead.
Sorry.
The microphone is coming.
So that we mentioned dev and flat pack, so the next question is
what about other packaging formats like OS native, for example,
RPM or any other, like, I don't know, like something for
ARCH or anything else?
Yeah.
I mean, that would be cool.
There's definitely been conversations over RPM.
Yeah, we're thinking about it.
My question will be if you're supporting dev now and all these
packages, is it not a burden for you to continue supporting more?
Don't you have a plan to focus on something more straightforward?
It is true that we're taking on more work by supporting these
packages, but I think we wanted to offer that support to the
Linux community.
That's, yes.
Thank you.
Are you going to be working with projects like Debian to
promote the Mozilla repositories for their, like, stable user
bases?
Yeah, we, the Debian package maintainer is a Mozilla
employee, he helped us out with this.
Yeah, it's just a different package, it's a different set of
trade-off, right?
There's a lot of different guidelines when you build the
package for the distribution and different infrastructure
limitations and things like that.
So it's more like an alternative package for people that find
it useful.
Thank you.