Open Bug 1249971 Opened 5 years ago Updated 7 months ago
Image to distribute Firefox binaries for linux
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.
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?
Rail has been dealing with the snap file format. He can probably give you more information than I
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?
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Assignee: nobody → probono
Severity: enhancement → trivial
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
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 <email@example.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 firstname.lastname@example.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 <email@example.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.
Component: CIDuty → RelOps: General
Component: RelOps: General → General
Product: Infrastructure & Operations → Release Engineering
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.