Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 01:34:27PM +0100, Mike Hommey wrote:
> On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote:
> > Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit :
> > > I favor a combination of idea one and two, which is: Keep 3.5 in
> > > unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to
> > > unstable when it's out.
> > >
> > > Then we have one big break and a tested 4.0 in unstable.
> > I’d favor that one too. The sooner we can adapt reverse dependencies to
> > 4.0 in experimental, the better. And no need to do the work twice.
> There have been almost a year to adapt reverse dependencies to 3.6 in
> experimental. And I don't think most rdeps are ready for 3.6. Do you
> expect things to be significantly different?
Three months later, I see no significant change in the reverse
dependencies status. At the moment, we're stuck with 3.5 in testing and
unstable, and 4.0 in experimental.
This deeply sucks.
However, by the time wheezy is released, Firefox will have had several
new releases. And the current embedding API (gtkembedmoz) has already been
removed from Firefox 5.0, coming in a few weeks. We're obviously not
going to maintain xulrunner 1.9.1 or 1.9.2 forever, so at some point,
things relying on gtkembedmoz will have to either contribute to mozilla
to get a new embedding API that works better for them (it would be about
time), or die. Waiting for that to happen, the only solution forward is
IMHO to remove packages using gtkembedmoz.
Packages relying on xulrunner-dev to build plugins should still be fine,
though. As for libmozjs, the API is a fast moving target, and AFAIK,
only a few packages such as gjs are following the trend. Others should
probably die too.
The Debian Mozilla team just doesn't have the resources to handle the
situation entirely. We (sic) can't fix all rdeps that can be fixed (here
I'm thinking things that can switch to something else than xulrunner,
like kazehakase, but I think that one was RMed), and sort out the other
rdeps status on our own. Past and present experience suggests that
nothing is ever going to happen in experimental, so I guess the only way
to get things moving is a painful massive breakage in unstable.
What's the release team take?