xulrunner 1.9.2 into sid?

Mike Hommey mh at glandium.org
Mon Jun 28 08:34:06 UTC 2010


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.

Long answer:
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
party repository.

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
either.

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
trivial software.

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
see below.

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.

Cheers,

Mike



More information about the pkg-mozilla-maintainers mailing list