Description of problem: A hand-upgrade of Firefox 1.5 to Firefox 2.0 cannot be done simply and cleanly because devhelp and yelp depend upon gecko-libs which is provided by Firefox 1.5. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. rpm -e firefox Actual results: error: Failed dependencies: libgtkembedmoz.so is needed by (installed) yelp-2.16.0-15.el5.i386 libgtkembedmoz.so is needed by (installed) devhelp-0.12-11.el5.i386 libxpcom.so is needed by (installed) yelp-2.16.0-15.el5.i386 libxpcom.so is needed by (installed) devhelp-0.12-11.el5.i386 libxpcom_core.so is needed by (installed) yelp-2.16.0-15.el5.i386 gecko-libs = 1.8.0.12 is needed by (installed) yelp-2.16.0-15.el5.i386 gecko-libs = 1.8.0.12 is needed by (installed) devhelp-0.12-11.el5.i386 Expected results: Removal of Firefox 1.5, as a simple easy way to make the way clear to hand install Firefox 2.0 should JUST WORK. Additional info: This is a new dependency on libraries from Firefox 1.5 introduced between RHEL 4 and RHEL 5. It will complicate the eventual upgrade to 2.0. The GNOME integration should not have done this. This dependency stands in the way of MIT going site-wide to Firefox 2.0. Firefox 2.0 is in place on our Macs, our Windows (even Vista systems), and our RHEL 4 systems. This is an obstacle to roll-out of RHEL 5 at MIT to replace RHEL 4.
reference links : From FedoraProject wiki http://fedoraproject.org/wiki/Firefox2. From Fedora Planet http://remi.collet.free.fr/index.php?2007/07/18/386-firefox-2005-1
How does Red Hat reconcile not including Firefox 2.0 with the recommendations of the Mozilla Project, which says: "Firefox 1.5: This version of Firefox is no longer supported with security and stability updates. We strongly encourage all users to upgrade to Firefox 2." (from the bottom of http://en.www.mozilla.com/en/firefox/all.html) The Mozilla project has said that Firefox 1.5.x will only be maintained with security updates through May 2007. It is now July 2007. Does this mean that Red Hat will take over security audits of the Firefox 1.5.x code and craft all security and bugfix updates themselves rather than get them from the upstream maintainers? Or will Firefox 1.5.x simply be allowed to suffer from bit rot? Given how much emphasis Red Hat Enterprise Linux places on stability, it's kind of unfortunate that the supported way to get Firefox 2.0 is from an experimental (that term is used on the Fedora Wiki page) RPM for Fedora.
If you are using RPM packages provided with RHEL, then the EOL does not affect you. Your support comes from RHEL which will not EOL anything in the RHEL line for a long time.
I'm aware that the EOL does not affect whether or not we receive support. What I'm more concerned about is how to explain to our customers (particularly our professors and students, who don't like vague, hand-waving explanations) why we cannot offer a fully supported version of Firefox 2.0. Can Red Hat offer some sort of official statement or press release as to why Firefox 2.0 was not included in RHEL 5? I do not believe the Fedora Wiki referenced earlier constitutes such a statement (because, well, it refers to Fedora, not Red Hat Enterprise, and there's certainly precedent for RHE doing things different from Fedora). The fedora-devel posting linked from the wiki is also not that useful for end users. In fact, it's downright insulting for a customer asking about Firefox 2.0 to be referred to a mailing list thread which states unequivocally that "most people really don't care" and "There is nothing extremely compelling about Firefox 2.0" Yes, Firefox 3.0 will be an improvement, there's no doubt about that. But it's not out yet. It's current estimated release date is November. And if past experience is any indicator, a major version bump like that won't make it into a quarterly update for RHEL 5. If, in fact, there are plans to include Firefox 3.0 in a quarterly update for RHEL 5, then that's great, and we'd love to hear about them, because we could mollify our users for 3 months. If, however, Firefox 3.0 will not make it into Red Hat Enterprise until RHEL 6, then we have a problem.
Let me chime in on the "Red Hat will support you with Firefox 1.5" front. We have some experience both with Red Hat and with Mozilla.org in working through problems. We have successfully worked upstream with Mozilla.org to discuss issues and to get them resolved in a dialog that balanced MIT's needs with Mozilla's needs. While we didn't always get what we wanted, we came away from the experience mostly believing in the process. So far I can say that with the past 3 years as a Red Hat Enterprise customer, to put it as diplomatically as I can on an open channel, our expectations have not been met, and we do not have much confidence in the process. Mozilla.org is a credible support provider for Firefox. Red Hat is not. It may be that leaning a bit on Fedora is exactly the way forward, but so far the gap to jump still seems quite wide.
Sorry Ritesh, you have to work a little bit harder. The Fedora page you pointed to provided a lot of interesting threads. With a fair bit of work I much better understand the situation. The remi repository (after I did the work of translating the caveats in french via google language tools) points out the SAME CONFLICTS THAT ARE THE BASIS OF THIS BUG. So, let me finish doing the work you started: 1. If you go to the Firefox 2.0 web page, you discover that the link to the experimental development version is broken. That page needs to be updated to either not talk about a development version, or to point to its proper place now that FC7 has been released. 2. The current known complete list of conflicting dependencies with the gecko libraries (from the remi repository) are: devhelp, epiphany, galeon, gnome-python2-gtkmozembed, liferea and yelp. 3. The person who is the decider for packaging of Fedora, who is also a well respected liaison to Mozilla, and the primary Firefox maintainer (and who probably does most of the work of the 1.5 support for Red Hat) is Christopher Aillon. 4. The functionality-based reason Aillon gives for not going to Firefox 2 is that it breaks a lot of things, and requires complex re-integration for very little useful additional functionality. He mentions that in some places, 2.0 contains regressions from 1.5. Much of what breaks is cleanly dealt with in Firefox 3. So his strong preference is to break things for customers once in the transition from 1.5 to 3, minimize work, and maximize the value of effort expended. Aillon classifies most of the Firefox 2 stuff as a marketing gimick more than anything else. 5. The Linux Alliance described in December 2006 in Aillon's blog and pointed to by the Fedora Firefox2 web page describes how Mozilla, Novell, Red Hat, Ubuntu and the other Linux distributions are going to work better together through a new collaboration. The distributions, such as Red Hat and Novell will take on the work to support 1.5 past Mozilla's EOL of 1.5. Following some further threads I see reports of Firefox 3 doing well for Linux as Aillon expected. ---- Ok with all that, where are we now? Firefox 3 is progressing nicely. But Mozilla's marketing has succeeded too well. The Mozilla auto-updater in 1.5 for Windows and Mac to take 2.0 probably helped a lot, even on top of Mozilla's strong statement of de-support. Mozilla's strong statement of de-support has not been answered by a strong statement of support by Red Hat. Sorry Red Hat, "trust us" is not enough. The details of: "These specific things break, those functions are not important, and we're collaborating with Novell on support," were crucial to building credibility but those details were never communicated, and it took me four hours of chasing around the net to learn them. Now we're living in a world where Red Hat established a strategy, had the business relationships to make it work, and the technically correct reasons for adopting it. Ubuntu, Windows and MacOS standardized on Firefox 2.0. Red Hat never communicated the details, rationale, or anything else to strengthen its position. Its marketing message failed whereas Mozilla's Firefox 2.0 marketing message succeeded. Red Hat did the smart thing but looks stupid now. How are we to proceed? MIT is a site that wants to adopt applications as soon as they are stable, and widely used. MIT's previous experience with Open Office is that Red Hat forced us to wait way too long. That perception is also present for Firefox 2. Because Red Hat didn't follow up to support its decision properly, as I said, they did the smart thing but look stupid. MIT customers are walking away from the RHEL 4 and RHEL 5 solutions I offer in my role as Linux Platform Coordinator, and adopting solutions they more strongly believe in such as Ubuntu. The thing that I would like is a channel I can put on the MIT Satellite Server that can update Firefox 1.5 and those things it depends upon to Firefox 2.0 in a way that will gracefully allow the eventual Red Hat update to 3.0 or 2.0 or whatver is standard when the time comes. I suspect that Red Hat does not have the resources to do these builds, and that Chris Aillon would be the one to do the work, and he's very busy executing on his sensible strategy. So I have the choice: Tell customers they can't have the browser everyone else has, and watch them wander off to Ubuntu, or become an expert in system packaging and create the solution that Red Hat probably should have caved in on and offered on May 1 2007. Bottom line: My skepticism of the Red Hat strategy and problem resolution process continues.
With regards to a consortium to support 1.5, apparently SuSE caved, and left Red Hat alone. I just found the 19 March 2007 press release announcing SuSE Sled 10 Service Pack 1 specifically states that SuSE went to Firefox 2.0. Note that the SuSE update system is pretty fragile, and it will be a while before my test system is updated to SP1 to confirm this press release. As correct as the decision was to stick with 1.5, the reality is that Red Hat looks like the lone wolf sticking to an obsolete version.
Well, it bounced around a lot, but my SuSE test system is now running their "Service Pack 1". (Don't ya love how they adopt Microsoft-ish nomenclature :-( ) Anyway, indeed it DOES have Firefox 2.0.0.2. How does it get past the library conflicts? It installs mozilla-xulrunner 1.8.0.1-32.2 yelp depends on that. I thought xulrunner, the solution to this problem was Firefox 3.0 only?????
https://www.redhat.com/archives/redhat-academic-list/2007-July/msg00104.html has a good summary of things.
Created attachment 160458 [details] Summary of Rationale for and implementation of RHEL 1.5 Firefox Strategy That link is now broken because the discussion list had been made public without the consent of the members. The list might open back up to publicly visible in the future. Content-wise, that summary only covered why Red Hat Support of 1.5 is worthy of trust. It did not cover the rationale for why 1.5 is good and 2.0 is bad. Digging out that rationale and summarizing it turns out to be a non-trivial task. Attached is the current draft of documentation I have drafted to help the MIT customers of RHEL 5 understand the situation. I believe this is a definitive summary of the issues. But if I've missed something do please reply and I'll make an update to what we tell our customers.
FF2 package ith parallel install support. This is a bad HACK. http://people.redhat.com/rkhadgar/firefox/
gecko-libs is now provided by xulrunner and firefox3 will be released in 5.2. Closing as WONTFIX.