Why Firefox isn't on Flathub?

I’m aware that there is a Flatpak repo for Firefox, but why isn’t moved on Flathub? thus Firefox could also been dropped from the base image

and further more it would be nice to have a browser choice in Sb; for example since it uses GNOME it could had GNOME Web App pre-installed (as Flatpak), and first time you open it, it could ask us for what browser we want to use, and give us installation links/instructions

3 Likes

The Flatpak FF repo is suffering a bit, most particularly it’s still on GNOME SDK 3.26 (based on fd.o 1.6), though I know someone who’s getting it working on 3.32 (will update here once that’s done).

IIRC the official website says something to the effect of, it’s not on Flathub because of the timely nature that security fixes would have to be pushed out, so they’re waiting for Mozilla to pick it up.

That being said, there should hopefully be a Chrome Flatpak as well SOON™.

4 Likes

Google’s Chrome browser is proprietary software.

1 Like

I’m assuming Gnome Web, Firefox, Chrome, Chromium, Brave, etc. will come to Flathub eventually. I guess web browsers are relatively difficult to package. But indeed for starters GNOME would do well to publish all of it’s (core) applications as Flatpaks on Flathub, and Web is one of few that’s still missing currently.

I feel like this argument went out the window with Flathub recently adding a lot more CI/CD features to its infrastructure. Seems like they have made it easier to automatically create and publish new builds. Not sure if they have a webhook yet for upstream CI/CD systems to trigger, but it surely can’t be unsuitable for Firefox by now.

This is not a blocking issue for Flathub. There are various Flatpaks published there that are wrappers around pre-built proprietary binaries. Like Visual Studio Code. It even comes with a nice statement in the description:

This is the proprietary Microsoft build of Visual Studio Code, packaged into a Flatpak. This repackaging is not supported by Microsoft.

1 Like

They don’t unfortunately, though at this point I’m hoping this renewed interest in updating it might encourage them to look at it again.

I know there are plans to add e.g. auto updates based on deb packages (Endless already does this IIRC), so maybe it wouldn’t be too hard to add this via e.g. long polling. Since Flathub also has betas now, maybe FF Dev Edition could be added there…

1 Like

I run Firefox Nightly for the most part, although I also run Developer Edition sometimes. I install them in my home directory so the automatic updates work. I’ve tried the flatpaks but they don’t update, and every time you open them you have to re-pick them as default browser.

Due to the large and complex nature of the project, Mozilla is expected to distribute Firefox directly as a Flatpak package in the future (see Bug 1278719) and optionally (maybe) via flathub. However, it still depends on many unresolved issues and currently has no assigned dev. See the following response to see what other formats over time have failed.

As a user, I think that flathub is falling into the same problem that traditional packages in gnu/linux already have, which is to depend on third-party maintainers/packagers instead of being the same creators of the apps who distribute it in that way. Anyway, the framework/format (flatpak) is decentralized. Not all software should be in flathub IMHO.

The only regrettable thing about the previous point is that there is no directory where you can find software in flatpak format from different sources.

On the contrary. It’s making it easier than ever before for application developers to also handle their packaging and distribution themselves. GNOME’s apps are an example of that. Firefox would be such an example. Of course third-parties are not prohibited from making a Flatpak build file of an application if they fell like it or can’t wait. Thanks to Flathub’s centralization the packaging of many apps will become somewhat of a community effort, which is even better.

Yeah, but they’re not interested. In many cases for projects it is easier to create their own repo (like Jasp), their own distribution method (like Purism) or integrate it into their vision (like Elementary), and the point remains the same.

I don’t necessarily see separate remotes as a negative, Flatpak was explicitly designed with that in mind. Flatpak itself (the packaging format, not Flathub) has still largely been successful in allowing upstream control over distribution.

2 Likes

Yes, but the question is what kinds of remote the Fedora Project wants to include by default. Flathub is a third party repository like rpmfusion and you don’t get that in Fedora by default (with the exception of the new " Third Party Software Repositories"). I would expect Silverblue (once it’s an official edition) to ship with a full set of Flatpaks (Firefox + GNOME Core Applications) that are built in the Fedora infrastructure or provided directly by the upstream, without some kind of third party intermediary.

1 Like

I would guess that is the reason behind the push for modular, since there is existing tooling to go from modules to flatpaks, and with the fedora runtime going it only makes sense.

I agree, and I think flatpak (the platform) is meant for such. The links you note are a bit stale on the topic. I think flatpak will likely win over snap with Mozilla since it is distro agnostic

And this is supposed to be a good thing? How does Flatpak handle the fact that
they don’t have permission to redistribute this non-free code, and why in the
world is it proprietary to begin with? Unless I am mistaken, you can build
“Visual Studio Code” from source without proprietary software.

It has a system called extra-data that downloads the proprietary binaries on the host system.

Do we really have to bring free vs nonfree into every discussion? I understand you prefer FOSS software, which is entirely fine, but if someone is intentionally installing Chrome over e.g. the built-in FF, they likely have their own reasoning.

7 Likes

It is not about winning or losing, but analyzing the reasons why in that particular case you mention, Mozilla could already mantain a upstream SNAP package and publish it in Snapcraft. I don’t know the technical details, but I have read from some developers to say that it is much easier to work with snapcraft…

Anyway, the link I put was to show that Mozilla have worked on new proposals, but many of them are not carried out like the upstream *.deb, *.rpm, autopackage, etc. The idea of upstream Flatpak is there, but it seems a lot is missing for us to see it in practice.

Yes

True, ease of use goes a long way to help foster adoption, especially WRT under resourced efforts.

This is Fedora, so we certainly need to discuss the issues with proprietary
software. This is in line with the Four Foundations.

If somebody is attempting to install Chrome, for example, and an alternative
which is not proprietary (and offers the same features, etc) is available, we
should certainly mention it.

I do not hound users for their choices, and I have no desire to make anyone
feel bad about their decisions, however, my goal is to inform.

Why is it a good thing that Chrome is proprietary, that specifically a
proprietary copy of Visual Studio Code is being redistributed, while a Free
Software build could be shipped?

It is not necessary to inform when a user is aware of what they are requesting and yes, this is a fedora and for some time now the proprietary software has been opt-in…

Dude, nobody wants to talk about that here. Proprietary or free software is good to meet the needs of the user. If the proprietary software contradicts your ethics/moral/vision it’s fine, but it’s not something to discuss here.

Nevermind… Anything to say about why you think Firefox is not on Flathub?