Re: xulrunner 1.9.2 into sid?
On Sun, Jun 27, 2010 at 08:25:59AM -0600, Aaron Toponce wrote:
> Seeing as though upstream Firefox 3.6 released December 1, 2008, and
> upstream Thunderbird 3.1 released just a couple days ago, it might be
> high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and
> Icedove 3.1 will depend on it. However, I hear there will be lots of
> breakage if xulrunner 1.9.2 comes into Sid. If so, what will break?
> Further, what can I do to help?
Short answer: not much.
The target for squeeze was decided to be 3.5/1.9.1 a long time ago, when
testing freeze was expected much earlier. Until Thunderbird 3.1, the
incentive to keep it that way still made sense. Now, things may have
changed, but it's more complicated than it seems.
We currently only have one version of xulrunner in the archive for a
given suite. Technically speaking, the xulrunner source package provides
the xulrunner-1.9.x packages, and obviously a given source package only
provides on xulrunner-1.9.x package. At the moment, stable (lenny) has
xulrunner-1.9, squeeze and unstable have xulrunner-1.9.1 and
experimental has xulrunner-1.9.2. With the upcoming release of the
Firefox 4.0 first beta, there might be a xulrunner-2.0 coming in a third
Therea are mainly two reasons for that state of affairs with xulrunner:
- it avoids having a part of the suite using a version of xulrunner
while another part uses a different one, which would most probably
create a big mess.
- there is not enough hand power to maintain several versions of
xulrunner in the same suite (especially stable)
The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is
still considered as the release target: iceape 2.0, icedove 3.0, and
iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support
for stable will be easier if there is only one branch to support for the
whole gecko ecosystem. Sure, upstream support for it will be dropped
soon, but we can't expect 3.6 to be supported the whole squeeze lifetime
That being said, there are reasons why 3.6 would be nice to have in
squeeze, and the main one is the out of process plugin feature.
BUT, there are technical reasons that make that goal difficult to attain.
First, TB 3.1 has just been released, and as such hasn't been widely
tested in Debian. It usually isn't very wise, that close to the expected
freeze time, to upload a new major release of a not exactly small and
Second, for the reasons given earlier, releasing with iceweasel 3.6 and
icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
be a huge problem, as we already didn't release lenny with iceape, but
Switching to xulrunner 1.9.2 means making sure all the packages
currently built against xulrunner-dev and libmozjs-dev build fine, get
the proper dependencies, and then run fine with xulrunner 1.9.2.
Unfortunately, as xpcom is guaranteed forward compatible but not
backwards compatible, some plugins and extensions, once built against
xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This
would leave iceape users with a bitter aftertaste. Alternatively,
iceape-dev could be filled again with the relevant header and library
files, such that those plugins and extensions can build against it which
would solve the compatibility issue, but then iceape would need to
either be released or be left in the same state as in lenny, i.e. only
providing the -dev package. That means a lot of work in identifying
those plugins and extensions, modifying them, etc.
FWIW, as iceape-dev is not used anymore and is a transitional package, I
was about to remove it.
Switching to xulrunner 1.9.2 would also mean to make sure it works
properly on all the target architectures, while currently there are
various test suite failures on some architectures. xulrunner 1.9.1 is in
a better shape, from that perspective.
All in all, I still think releasing squeeze with iceape 2.0, iceweasel
3.5 and icedove 3.0 is the best course of action.