Make deb and rpm packages available for download

NEW
Unassigned

Status

()

Firefox
Build Config
--
enhancement
7 years ago
2 years ago

People

(Reporter: David Bruant, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dupeme?])

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.14) Gecko/20110221 Ubuntu/10.10 (maverick) Firefox/3.6.14
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.14) Gecko/20110221 Ubuntu/10.10 (maverick) Firefox/3.6.14

In a recent discussion (http://www.reddit.com/r/IAmA/comments/g197r/iama_were_on_the_firefox_development_team_and/c1k65l2), people suggested that Firefox could be made available as a .deb package or .rpm. I think it's a good idea. I am personally "converting" (non-tech) people to Ubuntu and they aren't confident with .tar.bz. Packages take care of everything for you and that's convenient.

Another idea would be to create a ppa repo?

Reproducible: Always

Comment 1

7 years ago
RPM - Bug 600317?
Whiteboard: [dupeme?]
(Reporter)

Comment 2

7 years ago
Bug 600317 targets nightlies and beta. I would also (and in priority) target stable releases. One issue with Ubuntu for instance, is that when a new Firefox major release comes out, (3.5->3.6 and soon 3.6->4.0), you have to wait until the next major Ubuntu release (or, I'm afraid, 2 for FF4) in order to have the new FF version.
Or, you can download it from the website, but in that case, it can only be a .tar.bz, but non-tech users are probably scared or feel uncomfortable extracting then clicking in one file in the middle of the repo. A .deb would make things easier for them: one thing to click, it creates an icon somewhere from which they can launch the program.
Opera does it: http://www.opera.com/browser/download/?os=linux-x86-64&ver=11.01&local=y
Chrome does it: http://www.google.com/chrome/eula.html?platform=linux&hl=fr

I do not see a major reason why Firefox wouldn't do it too.

Comment 3

7 years ago
This is a nice idea for an enhancement request. Setting as such.
Severity: normal → enhancement

Comment 4

7 years ago
FWIW, I haven't found any similar open non-mobile requests with the word “deb” or “debian” in the summary.
(Reporter)

Comment 5

7 years ago
(In reply to comment #4)
> FWIW, I haven't found any similar open non-mobile requests with the word “deb”
> or “debian” in the summary.
I haven't either. One of the rationale behind how I choose my bug summury is to try to fit all relevant words for text-searchability (that's why, my bug summuries are often long). Here, I chose "deb", "rpm", "packages", "download". "Linux" is searchable from the platform meta-data: no need to add it to the title itself.
Bugzilla SEO :-)

Comment 6

6 years ago
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110724 Firefox/8.0a1

Maybe Christian will have something to say about this. Adding him to the CC.

Comment 7

6 years ago
Not much to say, other than I agree we should have both for release :-). That being said, with the ppas and 3rd party yum repos I think this is fairly low on the priority list :-/

Comment 8

6 years ago
 Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110803 Firefox/8.0a1

(In reply to comment #7)
> Not much to say, other than I agree we should have both for release :-).
> That being said, with the ppas and 3rd party yum repos I think this is
> fairly low on the priority list :-/

Still, I am going to set this enhancement to New and, maybe sometime in the future, it will be addressed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #7)
> Not much to say, other than I agree we should have both for release :-).
> That being said, with the ppas and 3rd party yum repos I think this is
> fairly low on the priority list :-/

I would add, though, that ppas and 3rd party yum repos are easier to setup than mozilla shipping .rpm and .debs, if users want automatic upgrades (and we want them to have that).

And I don't know what Ubuntu and Fedora are going to do in the near future, but they might update Firefox to the latest versions for their releases every 6 weeks, since they are now also the security support for mozilla releases...

Comment 10

6 years ago
It does surprise me that, after all these years, Windows (.msi) and Linux (.rpm/.deb) Firefox still don't have a native install package for easy deployment. For the Linux platform, this could be achieved with a gradual scheme as follows:

1. Ensure that the 64-bit Linux platform is treated as equally as 32-bit in all cases - looking at the seeds/peers for recent torrent downloads of Fedora 16 showed that 64-bit is actually a more popular download than 32-bit. Hence, any new packaging format such as rpm or deb *must* be available in both 32-bit and 64-bit formats and promoted equally. Sadly, Mozilla is already failing on this front with their .tar.bz's (only the 32-bit version is offered for Web download, despite both 32-bit and 64-bit being official builds and both available via FTP download). Perhaps this 64-bit promotion failure should be filed as a separate bug?

2. Provide all the tools and data files require to create .deb and .rpm files on all the major Linux distros (Ubuntu and Fedora at a minimum). This may require the writiing of a top-level script to bring the whole process down to a one-liner command.

3. Actually start shipping 32/64-bit RPMs/debs in the same trees where the .tar.bz2 files live. Care will have to be taken to avoid clashes with standard distro repo packages of firefox(e.g. name the package mozilla-firefox perhaps [or at least a name that doesn't clash with Fedora's/Ubuntu's versions]). Whether Mozilla's RPM should replace the distro's Firefox install is up to debate - I'd be tempted to avoid that initially. Add download links for the RPMs/debs to the Firefox Web download page.

4. Set up Ubuntu and Fedora 32-bit and 64-bit repositories and perhaps release a "mozilla-release" RPM to set up the repo on Fedora (not sure if there's an equivalent on Ubuntu to add a repo via a "-release"-style package install). Add links to the repos/-release RPM from the Firefox Web download page.

It should be noted that Opera have already done steps 1 and  o3 and Google do step 4 too (there's a Google yum repository available that updates Chrome). Leaving the distros to do these steps themselves isn't satisfactory, particularly for long term releases (Ubuntu LTS, SuSE Enterprise, RHEL/CentOS), which lag behind major versions for their entire lifetime of up to 7 years (meaning those users miss out on new Web technologies).

Comment 11

4 years ago
http://kb.mozillazine.org/Installing_Firefox#Linux also shows the problem. Why Linux users have to fight with bash only to get (upstream) Firefox installed?

Distribution channel is certainly not reliable. (Why users' choice of browser versions have to fit distributions' vision?) Debian, for example, force users to use ESR version with a ugly icon.

Comment 12

4 years ago
It's also worth noting that even after the bash grind shown in the kb, Firefox is barely accessible from the command line. Further integration is left to end users.

See:
bug 296568
https://developer.gnome.org/integration-guide/stable/
Should bug 233548 be a marked as a dupe of this one (or the other way around)?

(I come here as someone who spent 90 minutes guiding someone through this *over the phone* yesterday :)
Duplicate of this bug: 1083830

Comment 15

3 years ago
What would actually be involved in implementing this? RPM and Deb package creation can be automated, so I assume there are points in build scripts that could be updated to do this automatically. Where would someone look to try and contribute that sort of work?

Updated

2 years ago
Duplicate of this bug: 233548

Comment 17

2 years ago
It would make things easier for me if RPMs were provided (ideally via a Mozilla-provided yum repository, but downloadable RPMs alone would at least be a step in the right direction). I'd like to start getting Firefox directly from Mozilla, as the Fedora packages take days just to make it into the testing repository, and then often take several more days to make it into the stable repository, leaving users exposed to security issues for far too long :-(
You need to log in before you can comment on or make changes to this bug.