Open Bug 1249971 Opened 9 years ago Updated 1 year ago

Use AppImage to distribute Firefox binaries for linux

Categories

(Release Engineering :: General, enhancement, P5)

Product:
Release Engineering
Component:
General
Platform:
All
Linux
Type:
enhancement

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: kskarthik91, Unassigned)

References

Details

(Keywords: feature) 

As we know, Currently Firefox is being distributed for linux users via their distribution repo's or as a compressed pre-compiled binary from the firefox download page.  

This method which i am proposing is called AppImage which relies on concept of 1 app = 1 file. This would allow Linux users to just download, chmod a+x, and run Firefox. Please consider providing an AppImage for firefox for linux users.

By distributing Firefox in the AppImage format, you could reach users on all major desktop distributions & also users can try multiple versions of firefox on the same host os. Also since the image file is always in compressed state & uncompresses only on execution. Thus, the disk space is saved. 

Cross-platform application projects like Scribus, Krita, and Subsurface (these are all Qt-based) are adopting AppImages as an easy way to bring bleeding-edge releases to users on all major Linux desktop distributions.

Source Code https://github.com/probonopd/AppImageKit

Some examples can be found at https://github.com/probonopd/AppImages

Although, the developer made a version of firefox(44.0) but if it comes from mozilla it gains a level of trust in the users.
Priority: -- → P1
Component: General → Platform Support
Priority: P1 → --
Product: Firefox → Release Engineering
QA Contact: coop
I second this and I am willing to do the work required if someone points me into the right direction. Where can I learn about the build system/CI servers used by Mozilla, and how could I add a build job for an AppImage there?
Flags: needinfo?(fabrice)
Flags: needinfo?(dietrich)
Flags: needinfo?(fabrice) → needinfo?(sledru)
Rail has been dealing with the snap file format. He can probably give you more information than I
Flags: needinfo?(sledru)
Flags: needinfo?(rail)
Flags: needinfo?(dietrich)
I briefly looked at the format. One of the downsides of the distribution for us will be implementing AppImage-specific update mechanism. With all complexity of the update rules, extra work to review the security risks of the update delivery mechanism, I'm not sure if we want to spend our limited resources. :(

Maybe AppImages should be a community driven project? At least in the beginning?
Flags: needinfo?(rail)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Assignee: nobody → probono
Severity: enhancement → trivial
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Severity: trivial → enhancement
I would like there to be an AppImage available for Linux. I prefer AppImage over alternatives as it does not require any additional components on the target computer, and it is quicker to deploy a single file compared to a folder containing hundreds if not thousands of files.
I'm currently on Debian and using an AppImage would be far more handy than anything. Quoting from probonopd:

"Providing an AppImage would have, among others, these advantages:

    Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
    One app = one file = super simple for users: just download one AppImage file, make it executable, and run
    No unpacking or installation necessary
    No root needed
    No system libraries changed
    Works out of the box, no installation of runtimes needed
    Optional desktop integration with appimaged
    Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
    Can optionally GPG2-sign your AppImages (inside the file)
    Works on Live ISOs
    Can use the same AppImages when dual-booting multiple distributions"
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
As much as I'd like to "take it and work on it", I have no clue where to start to lean about the Firefox build system. I've been making in-official AppImages from the original, upstream-provided binaries for quite a while now, and they have constantly been among the most popular of my proof-of-concept, in-official AppImages. To bring this to the next level, we'd need someone who knows the Firefox build system to have a look at this.

Rail <rail@mozilla.com> wrote above:
> One of the downsides of the distribution for us will be implementing AppImage-specific update mechanism

In fact, all Mozilla would need to do is to make an AppImage (and a corresponding zsync file) for each version as part of the build pipeline. AppImages can be updated using AppImageUpdate binary deltas; all of this is taken care of automatically (without additional work needing to be done to make or test specific update files). More information at https://github.com/AppImage/AppImageUpdate.
probono, a way to start to ask questions on the dev-builds@lists.mozilla.org 
and/or create bugs (marking them blocking this bug)
@probono has done amazing work with developing the AppImage specification and implementation. I truly wish that somebody @Mozilla would show him the respect he deserves and appreciate his offer to do the work to upgrade your build system.

AppImage is wonderful. To make an analogy, it's PortableApps for Linux.

I find that so many of my (virtualized) Linux environments lose the ability to install recent versions of apps because the package management system is no-longer being updated. For example, Fedora 21 can't run Chromium 60+ because the nss library can't be updated beyond 2.20. AppImage to the rescue! All of the most recent unofficial releases of Firefox published by @probono work perfectly. And while I do trust him, web browser security is HUGELY important.. and it would give some added piece of mind to be able to download these binaries directly from @Mozilla.
nobody else could say it better..

https://youtu.be/5PmHRSeA2c8?t=5m57s
This isn't the right place for such debate. This should be only the place for technical implementation.
It's sad to see that nobody is ready to help @probono even after 2 years ...
(In reply to probono from comment #6)
> Rail <rail@mozilla.com> wrote above:
> > One of the downsides of the distribution for us will be implementing AppImage-specific update mechanism
> 
> In fact, all Mozilla would need to do is to make an AppImage (and a
> corresponding zsync file) for each version as part of the build pipeline.
> AppImages can be updated using AppImageUpdate binary deltas; all of this is
> taken care of automatically (without additional work needing to be done to
> make or test specific update files). More information at
> https://github.com/AppImage/AppImageUpdate.

Sounds easy to implement. Nice work @probono!

(In reply to Sylvestre Ledru [:sylvestre] from comment #10)
> This isn't the right place for such debate. This should be only the place
> for technical implementation.

Why not? In theory there is nothing left to debate - not even technically.

Still happy to help making this happen. We could

  • Generate the AppImages as part of Mozilla's existing pipelines
  • Convert the binaries from the builds that get made already into AppImage format
    (without the need to have extra compile runs)
  • Generate .zsync files that will allow for incremental (think "binary diff") updates
  • Use libappimageupdate to make the AppImages updateable without the need for an external tool
  • Embed signatures

and much more. Just let me know what is needed, and how I can best help.

Here is what the LibreOffice project is doing:

AppImage developers are on #AppImage on irc.freenode.net.

Dave, can you please check this ?

Component: CIDuty → RelOps: General
Flags: needinfo?(dhouse)
Keywords: feature
Priority: -- → P5

Since this is building and packaging Firefox, it's more appropriate for Releng.

Component: RelOps: General → General
Flags: needinfo?(dhouse)
Product: Infrastructure & Operations → Release Engineering

I am not an technical person. But this doesn't seems like anybody is willing to help " probono". He is willing to learn and help you guys in the process of building an AppImage for Firefox. You guys should at least hear him out in technical perspective and try it. Then you should decide, is it worth your time & resources. Sorry, if I offended anyone and English isn't my first language so forgive my mistakes.

Why can't users of GNU / Linux systems have packaged programs similar to .exe or .DMG ?
AppImage is a good solution.

I must say that I would use an AppImage of Firefox were it available. I like the simplicity of setting them up and running them. I do not always bring my distro up to the latest version but I would use the newer Browser(s) as they roll out.

Yesterday a major (zero day) security patch was released in version 72.0.1 and the distros are playing catch up. Ubuntu 19.04 does not even show FF 72.0.1 in its updates. So by not providing an AppImage format all users of FF, who do not know how to install the latest firefox-72.0.1.tar.bz2 format over the existitng deb package, are left in a very vulnerable state.

+100 for FF in AppImage format.

I entirely agree with daya.sharma.

While I appreciate the passion in this bug, please realize that everyone commenting here (myself included) is in the minority. Not just in terms of OS choice -- Linux users historically makes up less than 5% of the overall Firefox user population -- but also in terms of being Linux users that would bother to update software outside of the update cycle of their chosen distro. Most distros disable the metrics in Firefox that Mozilla could use to gather more data (i.e. the update ping), and that absence of signal makes it hard for us to assert more about Linux users. :/

No one at Mozilla is debating that AppImage is a good general solution for software distribution. The question is one of smart application of scarce resources here at Mozilla. Since the majority of Linux users rely on their distros for updates, we're talking about a fraction of a fraction of users who would benefit from this. There is no strong, internal champion for this at Mozilla right now, which is why Rail suggested a community effort in comment #3.

If someone is interested, the first step would be to gain Try server access. I won't lie: this would be a hard hill to climb, but pretty much everything is defined in-tree these days, so at least you'd have a fighting chance when working on Try.

Mihai made a great progress with flatpaks today. I hope we'll get them ready soon.

Bah, probably a wrong bug. I mixed flatpaks and appimage :/

Surprised to see that Mozilla seems to be experimenting with other Linux packaging formats now but still not with AppImage.

Unlike most other formats, AppImage is specifically designed to be really distribution independent (hence addressing the Linux fragmentation), not controlled by a distribution vendor, and puts full control over the entire application distribution experience into the hands of application authors.

What would be the best way to engage in a meaningful discussion with Mozillians in order to better understand why there is no internal champion for this at Mozilla yet, and what would be needed to get Mozilla interested? I think there are answers to most if not all of the concerns raised in this thread.

As said before, I'd be happy to help make AppImages. I have been privately running Firefox from my own AppImages for almost a decade now, but I don't want to promote those since AppImage is all about "upstream packaging" where users get officially-built and supported applications directly from the trusted upstream vendors rather then from "random" third-party download pages or repositories.

See Also: → flatpak, 176101

We researched this subject and from what we saw, Flatpak has more adoption than AppImage. Feel free to correct me if I am wrong.

That being said, all the work done to enable Snaps and Flatpaks will probable make AppImage easier in the long run.

What exactly do you do to create your Firefox AppImage?

Here is a simplified example that shows how to turn the .tar.bz2 into an AppImage:
https://gist.github.com/probonopd/3d5d045619e3ff239b0a43406d75cd2e

This shows the basic mechanics. Things like zsync-based binary delta updates (the user would only have to download the bytes that have changed rather everything from release to release) are optional features of the format that could also be added.

(In reply to Mike Kaply [:mkaply] from comment #26)

We researched this subject and from what we saw, Flatpak has more adoption than AppImage. Feel free to correct me if I am wrong.

I really hope that the flatpak will eventually get somewhere. It seems, bug #1278719 is now 4 years old and the last comment was made a year ago. IMHO, flatpak is much more convenient in terms of system integration and auto-updating. (don't get me wrong, I also like AppImage but when you have to decide what to focus your energy on, it is clearly flatpak)

We're actually very close on Flatpak.

See:

https://bugzilla.mozilla.org/show_bug.cgi?id=1591387

AppImage and Flatpak do very different things. AppImage is about "one app = one file", no package manager and similar tools needed, nothing needs to be installed on the system, no root rights needed, simple.

Flatpak is not a substitute of AppImage.

There are tools for AppImage binary delta updates, they can even be built into the Firefox AppImage. I still hope that one day there will be an official Firefox AppImage and I am happy to help. Just let me know what you need and we can make it happen.

Please discuss other package formats elsewhere.

Also, please remove the "Assignee" batch from me, as I don't know what I have been "assigned" to do and do not have any access to Mozilla's build infrastructure, hence cannot make an AppImage build job for Mozilla.

Please assign this to someone who has access to the Mozilla build infrastructure, someone who can actually do something on this issue. I am more than happy to help them.

s/batch/badge

Assignee: probono → nobody

Firefox on Mac, Win, Android, etc... But still not an official Appimage for every Linux users ?

Update the permissions to limit comments for people with editbugs permissions:
we had enough "me too" comments.

We know that it would be great to have it. We have worked on flatpak&snap and we are working with Linux distro on a regular basis to get Firefox in the package systems (Debian, Ubuntu, Fedora, Redhat, etc). We cannot support ourselves every Linux format but we will be happy to take patches.

Restrict Comments: true
See Also: 176101 → snappy
Severity: normal → N/A
You need to log in before you can comment on or make changes to this bug.