Please package a version of Firefox without SSE2
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| firefox (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
As has been noted in Bug 1697800, Firefox now dies on machines which Ubuntu still supports (i686). This is a critical problem as Firefox was the only modern web browser that did not require the SSE2 extensions and Ubuntu has committed to long term support for machines without SSE2.
While Bug 1697800 is dealing with the urgent matter of Ubuntu systems breaking right now, I'm filing this bug to request a long term solution. According to Mozilla's Support page (https:/
"The processor requirements of Firefox as distributed by Linux distributions may differ from the processor requirements of Firefox as distributed by Mozilla, so you may be able to obtain an up-to-date version of Firefox that does not require SSE2 from your Linux distribution."
I don't know how hard this would be, but could the Ubuntu-Mozilla Team please look into compiling a version of Firefox that does not require SSE2?
Thank you.
| hackerb9 (hackerb9) wrote | #1 |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in firefox (Ubuntu): | |
| status: | New → Confirmed |
In Bug 1697800 Seth Arnold points out that the upgrade tools are not in a position to check architecture features before installation. While I don't know the best (least worst?) solution, here are some ideas.
Option A) Compile the SSE2 parts of Firefox in a separate library and place it in /usr/lib/sse2/. I have read that the Linux kernel already searches that directory first on processors that support that feature. A solution using libraries would make sense as it's how we already handle similar situations of binaries that only work on certain types of hardware (e.g., graphics cards, 32bit/64bit). This might require working with the Mozilla folks to convince them to isolate the code.
Option B) Create a new package "firefox-i686" (for processors without SSE2), rename the current firefox to "firefox-i786", and then make "firefox" a meta-package that picks the right one. I don't know enough about meta-packages to know if this is actually feasible.
Option C) Create a new dpkg architecture "i686" which will only contain binaries that can actually run on 686 class processors. Rename "i386" to "i786" to reflect reality. While tedious to implement and perhaps a redundant use of disk space for 99.9% of the binaries, it is fairly straightforward to do and is perhaps the "correct" solution.
Option D) Add a new APT repository such as "xenial-i686". This is similar to (c) but lazier. The xenial-i686 repository would contain very few programs, just the ones, like Firefox, that had to be compiled differently than the ones already supplied in the standard repository. This has the downside that there is no way to indicate to the end user when a package is not available at all for the i686. It is also perhaps a misuse of repositories when that's what architectures are for.
Option E) Bite the bullet and rewrite the package tools to handle ABIs that are nearly, but not quite, identical. This would be handy as we approach programs that require SSE3, SSE4, SSE4.1, etc. I don't know what this would look like, but I presume it'd require a lot of discussion first.