[Novalug] Firefox versioning
Bryan J. Smith
b.j.smith at ieee.org
Wed Dec 16 11:55:50 EST 2009
[ Posting this to the list ]
Red Hat - Backporting of Security Fixes:
Anything and everything you've _ever_ wanted to know on how
Red Hat platform (e.g., Enterprise Linux), middleware (e.g., JBoss),
etc... products when it comes to security updates (definitely note the
various pages on the left bar):
Application Binary Interface (ABI) compatibility is the ultimate consideration
for Red Hat in the platform -- Enterprise Linux (EL). Red Hat extensively
tests and regression tests even security fixes before release, hence why
Red Hat may not be the absolutely quickest with a security errata by a
few hours (for those that like to brag they are). At the same time, I've seen
a lot of "booms" for non-EL (or EL rebuilds) because they don't. Ensuring
customers can update without breakage, regressions or other issues is
just as important as the security fix itself. I know of one major distributor that
failed to become a standard server OS at Dell because of this during Dell's
testing to make it a peer to Novell and Red Hat offerings a couple years ago.
In the case of Firefox, Red Hat _skipped_ Firefox 2.0.x completely.
It shipped Firefox 1.5.x and _only_ rebased to Firefox 3.0.x with
Enterprise Linux (EL) release 4 update 7 (EL4.7) and release 5 update
2 (EL5.2) IIRC. Red Hat avoids rebasing as much as possible with it's
EL releases, so don't expect any rebate to Firefox 3.5.x. Red Hat will
handling it's own backports, sometimes even after Mozilla has not merely
deprecated the release, but no longer supports it -- depending on various
factors. Firefox 2.0.x was skipped for many reasons (including bugs), but
a major reason Firefox 3.0.x was adopted was to segment XULRunner
from Firefox (so GNOME would only have a dependency on XULRunner,
not all of Firefox).
I know first-hand that changes in Firefox 3.0.x profiles from Firefox 1.5.x
caused a few headaches for a few customers. Red Hat notified and
tested with early adopters with the assumption that standard desktops would
require changes in their mandatory, default and/or user prefs.js with the
rebasing -- and did this for over a year before the rebase was done. Hence
why, again, rebasing is avoided at all costs. Red Hat is heavily funded by
subscriptions because it avoids these issues - it's customers pay for that
sustaining engineering and related testing and regression avoidance. The
great majority of customers were prepared. Others that did not heed the
warnings had major headaches (and, in general, were not following all the
notifications that were sent out, the early adopter channel for testing, etc...).
Introducing Firefox 3.5.x would be as bad of an idea as Firefox 2.0.x for
EL4 and EL5 at this time. Mozilla is still supporting and updating Firefox
3.0.x as well, so there is no reason to put customers through another rebase.
P.S. If you really want Firefox 3.5.x, then grab the tarball, install it in
/usr/local/lib/firefox-(ver). Then apply your SELinux security contents
using the system's Firefox 3.0.x tree as a reference (chcon --reference=).
That's what I do if I really need Firefox 3.5.x features. I also use it to run
the old Firefox 1.5.x release for compatibility with some web app servers.
Bryan J Smith Professional, Technical Annoyance
Linked Profile: http://www.linkedin.com/in/bjsmith
Red Hat: That 'other' American software company built on
open customer selection of options and value, instead of
controlled distribution channels of forced bundle and lock
----- Original Message ----
From: Megan Larko <larkoc at iges.org>
To: NOVALUG <novalug at calypso2.tux.org>
Sent: Wed, December 16, 2009 11:10:54 AM
Subject: [Novalug] Firefox versioning
I am curious again about software package version numbers. I recall from past experience that
sometimes security patches and bug fixes are put into software packages which may use a slightly
different version number than the main software host site (usually for downloads and installs from a
source tarball, for example). My curiousity was piqued by a Windows Vista set of patches for the
Firefox web browser (the patches are invoked from the firefox setting to notify the user of new
patches) which reflect the firefox software version on the http://www.mozilla.com website using
version number 3.5.6. Looking at the patch information, some of the patches seem to be a very
good idea. I set myself to upgrading firefox on my CentOS 5.3 and Ubuntu 9.04 Jaunty systems.
Both of the two latter systems indicate that they are current on firefox software version via yum
for CentOS and wajig for Ubuntu. The firefox version for those two systems is 3.0.15-3 (CentOS)
and 3.0.15 (Ubuntu 9.04).
My understanding is that 3.5.6 is a major version modification from 3.0.15 (based on my limited
understanding of the significance of the second digit in a version number).
Finally my question: Do I need to uninstall firefox linux package to get the 3.5.x series or are
there linux version number events going on to keep the deps in line?
Ubuntu 9.04 sample:
larkoc at larkoc-Ubuntu:~$ firefox --version
Mozilla Firefox 3.0.15, Copyright (c) 1998 - 2009 mozilla.org
larkoc at larkoc-Ubuntu:~$ sudo wajig upgrade firefox
[sudo] password for larkoc:
Reading package lists... Done
Building dependency tree
Reading state information... Done
firefox is already the newest version.
The following packages were automatically installed and are no longer required:
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
larkoc at larkoc-Ubuntu:~$ cat /etc/lsb-release
Novalug mailing list
Novalug at calypso.tux.org
More information about the Novalug