Red Hat Bugzilla – Bug 249632
[RHEL5] yelp depends on Firefox libraries preventing simple hand-upgrade to 2.0
Last modified: 2008-02-29 08:04:58 EST
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):
Steps to Reproduce:
1. rpm -e firefox
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 = 126.96.36.199 is needed by (installed) yelp-2.16.0-15.el5.i386
gecko-libs = 188.8.131.52 is needed by (installed) devhelp-0.12-11.el5.i386
Removal of Firefox 1.5, as a simple easy way to make the way clear to hand install Firefox 2.0 should
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
From Fedora Planet
How does Red Hat reconcile not including Firefox 2.0 with the recommendations of the Mozilla Project,
"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
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 184.108.40.206.
How does it get past the library conflicts?
It installs mozilla-xulrunner 220.127.116.11-32.2
yelp depends on that.
I thought xulrunner, the solution to this problem was Firefox 3.0 only?????
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.
gecko-libs is now provided by xulrunner and firefox3 will be released in 5.2.
Closing as WONTFIX.