There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla® camp, that I, as the Firefox® co-maintainer, the xulrunner maintainer, and (soon) Seamonkey™iceape co-maintainer, have to rectify.
They broke the --enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox® at the appropriate places in the build tree so that we could have Firefox® with the "unbranded" logo instead of the official logo, as Gervase Markham gave us authorization for. You're still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken.
Firefox® logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla® has unnecessarily given a non-free license to "clarify" the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period.
Debian isn’t properly collaborating with Mozilla®, sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum's blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in... that's exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming.
The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas's blog again).
So, let's dig into our firefox_2.0~rc1+dfsg-1.diff.gz:
- Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
- Changes to fix "make distclean" so that it really cleans the build directory,
- Change not to build the "mangle" utility,
- Change not to call netstat to generate entropy, which is useless on linux,
- Changes to make Firefox® build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla® guys don't seem to care much for,
- Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
- Change to allow to build flat chrome without the zip utility,
- Change to allow to use system library for myspell, instead of statically linking the bundled one,
- Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
- Changes to work around bugs with the hidden visibility pragma on gcc,
- Changes to make the pango backend actually build correctly,
- Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in's,
- Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
- Change not to build useless chromelist.txt files,
- Changes to make helper applications with parameters work,
- Changes to allow builds against GTK 2.8,
- Changes to work around an Xrender bug,
- Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences...),
- Change to allow mice extra buttons to act as something else than a left button,
- Change to allow to build with -Wl,--as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions' components,
- Changes not to shlibsign the NSS modules at build time, since we're stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.
That's not that many changes, and most of them were taken from either some Mozilla® CVS trunk or the Mozilla® Bugzilla™. And most of those that were not taken from there have been sent, except those that really don't make much sense outside Debian. So, where are these frozen API changes ?
And we're not properly collaborating, huh ?
The Mozilla® project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett's blog)
That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I'm not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions.
The only main difference now, between the official Firefox® and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won't explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files.
Now, a little bit about differences the Mozilla® guys don't seem to care about while they really should: distributions build the Mozilla® products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox® that is linked against libstdc++6. You are lucky if that setup doesn't crash.
Little extra from comments in Lucas's blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla’s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more.
Update:
Debian is going to replace Firefox® with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox® with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox® when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name... that's quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can't and won't do more than a rename for the moment.
Update 2:
We (Mozilla®) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla® Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it's Ubuntu, it's fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes.
Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.
