Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 160458 Details for
Bug 249632
[RHEL5] yelp depends on Firefox libraries preventing simple hand-upgrade to 2.0
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
Summary of Rationale for and implementation of RHEL 1.5 Firefox Strategy
ff2.0-rationale.html (text/html), 3.65 KB, created by
wdc
on 2007-08-01 20:08:24 UTC
(
hide
)
Description:
Summary of Rationale for and implementation of RHEL 1.5 Firefox Strategy
Filename:
MIME Type:
Creator:
wdc
Created:
2007-08-01 20:08:24 UTC
Size:
3.65 KB
patch
obsolete
><html> ><head></head> ><body> ><h4>Firefox 1.5 not 2.0</h4> > <p>Mozilla.org made a big push to get everyone to switch from > Firefox 1.5 to 2.0, and de-supported Firefox 1.5 in May > 2007. Red Hat, SuSE, and other distributions established a > collaboration to continue supporting Firefox 1.5 after Mozilla > discontinued support. </p> > <p>The rationale for sticking with 1.5 was:</p> > <ul> > <li>There were costs involved in dealing with subsystems that > had started using libraries from Firefox (devhelp, epiphany, > galeon, gnome-python2-gtkmozembed, liferea and yelp), and in > dealing with migration issues for plug-ins and extensions > based on Firefox 1.5. </li> > <li>Firefox 2.0 had re-introduced bugs that had been fixed in > Firefox 1.5 for rendering international characters, printing, > cascading style sheets, security and random application > freeze-up.</li> > <li>RSS handling took a step backwards in functionality. </li> > <li>The new functionality in 2.0 was deemed not significant > enough to deal with the costs and regressions. </li> > <li>A consortium of Linux distributions including Red Hat, > SuSE, Ubuntu and others formed to continue supporting Firefox > 1.5 after Mozilla.org support ended.</li> > <li>Significant improvements to behavior under Linux and > cleaner support of applications wanting to use the > Mozilla-supplied libraries were slated for Firefox 3.0. </li> > <li>Red Hat made the primary focus of Enterprise Client to be > customers with large deployments that could not easily take an > upgrade to Firefox.</li> > </ul> > <p>With a support consortium in place, a pathway to good code > and significant functionality improvement established, and the > committment to not forcing big changes on customers, Red Hat > locked itself in to Firefox 1.5. </p> > <p>It is unfortunate that the other members of the Linux Firefox 1.5 support consortium seem to have caved to the Firefox 2.0 marketing push. All the other distributions offer 2.0 either by default or as an option. This makes Red Hat's carefully reasoned decision look like a bad one.</p> > <p>There are options for installing Firefox 2.0 on Red RHEL but they create problems:</p> > <ul> > <li>Firefox 2.0 and 1.5 profiles are incompatible, so you need > to use the profile manager and be very careful never to run > 1.5 on your 2.0 profile. When the time comes to update to the > new version of Firefox from Red Hat, you will need to be very > careful that the right profile migrates over and becomes your > one and only.</li> > <li>Removing Firefox 1.5 completely would eliminate the > profile conflict, but then the applications that depend upon > the Firefox 1.5 libraries (devhelp, epiphany, galeon, > gnome-python2-gtkmozembed, liferea and yelp) would break.</li> > <li>Adopting an early release of xulrunner would eliminate the > library conflict, but that release is not maintained, and > contains known security problems.</li> > <li>MIT could craft shadow RPMs that replace the dependent > subsystems and Firefox, but dealing with any updates by Red > Hat to the dependent subsystems or Firefox would be messy. If > both MIT and Red Hat did not agree perfectly on the version > numbering, systems could get into a state where nothing could > be installed until a careful removal of components was made by > a wizard.</li> > </ul> > <p>Bottom Line: No Firefox 2.0 for Red Hat Enterprise Linux. </p> ></body> ></html>
<html> <head></head> <body> <h4>Firefox 1.5 not 2.0</h4> <p>Mozilla.org made a big push to get everyone to switch from Firefox 1.5 to 2.0, and de-supported Firefox 1.5 in May 2007. Red Hat, SuSE, and other distributions established a collaboration to continue supporting Firefox 1.5 after Mozilla discontinued support. </p> <p>The rationale for sticking with 1.5 was:</p> <ul> <li>There were costs involved in dealing with subsystems that had started using libraries from Firefox (devhelp, epiphany, galeon, gnome-python2-gtkmozembed, liferea and yelp), and in dealing with migration issues for plug-ins and extensions based on Firefox 1.5. </li> <li>Firefox 2.0 had re-introduced bugs that had been fixed in Firefox 1.5 for rendering international characters, printing, cascading style sheets, security and random application freeze-up.</li> <li>RSS handling took a step backwards in functionality. </li> <li>The new functionality in 2.0 was deemed not significant enough to deal with the costs and regressions. </li> <li>A consortium of Linux distributions including Red Hat, SuSE, Ubuntu and others formed to continue supporting Firefox 1.5 after Mozilla.org support ended.</li> <li>Significant improvements to behavior under Linux and cleaner support of applications wanting to use the Mozilla-supplied libraries were slated for Firefox 3.0. </li> <li>Red Hat made the primary focus of Enterprise Client to be customers with large deployments that could not easily take an upgrade to Firefox.</li> </ul> <p>With a support consortium in place, a pathway to good code and significant functionality improvement established, and the committment to not forcing big changes on customers, Red Hat locked itself in to Firefox 1.5. </p> <p>It is unfortunate that the other members of the Linux Firefox 1.5 support consortium seem to have caved to the Firefox 2.0 marketing push. All the other distributions offer 2.0 either by default or as an option. This makes Red Hat's carefully reasoned decision look like a bad one.</p> <p>There are options for installing Firefox 2.0 on Red RHEL but they create problems:</p> <ul> <li>Firefox 2.0 and 1.5 profiles are incompatible, so you need to use the profile manager and be very careful never to run 1.5 on your 2.0 profile. When the time comes to update to the new version of Firefox from Red Hat, you will need to be very careful that the right profile migrates over and becomes your one and only.</li> <li>Removing Firefox 1.5 completely would eliminate the profile conflict, but then the applications that depend upon the Firefox 1.5 libraries (devhelp, epiphany, galeon, gnome-python2-gtkmozembed, liferea and yelp) would break.</li> <li>Adopting an early release of xulrunner would eliminate the library conflict, but that release is not maintained, and contains known security problems.</li> <li>MIT could craft shadow RPMs that replace the dependent subsystems and Firefox, but dealing with any updates by Red Hat to the dependent subsystems or Firefox would be messy. If both MIT and Red Hat did not agree perfectly on the version numbering, systems could get into a state where nothing could be installed until a careful removal of components was made by a wizard.</li> </ul> <p>Bottom Line: No Firefox 2.0 for Red Hat Enterprise Linux. </p> </body> </html>
View Attachment As Raw
Actions:
View
Attachments on
bug 249632
: 160458