Some thoughts about the handling of xulrunner-1.9.1 et al.

[Mike Hommey]

On Wed, Jul 08, 2009 at 09:30:47PM +0200, Axel Beckert wrote:
> Hi,
> 
> two things:
> 
> I just heard on the backports-users list from KiBi that there's
> ongoing work on xulrunner 1.9.1 and iceweasel 3.5 since quite a while
> ago.

A while ago ? Work merely started a week ago.

> I'm quite disappointed that there weren't any hints about this or the
> corresponding blog posts on this list. Because that's the main reason
> why I subscribed to it: To get an idea of what's going on in Debian's
> xulrunner package and its relatives. Just a few days longer and I
> would have asked about the xulrunner 1.9.1 status quo on _this_ list
> (and not on backports-users as someone else did).

That's my fault, actually. I did some blog postings, but did not
announce on this list.

> The second thing is a question and a wish depending on the answer to
> the question. :-)
> 
> For how long will xulrunner-1.9 be around? In case it's not only a
> short overlapping period with xulrunner-1.9.1, I suggest adding
> something like /etc/alternatives/xulrunner, because currently
> xulrunner applications have to decide themself between two binaries
> with the version in the file name even if they would work fine with
> both.
> 
> Currently there's no possibility for the local admin to choose which
> of them should be used by default, e.g. conkeror currently only uses
> xulrunner-1.9 although it would work with xulrunner-1.9.1, too. (The
> git version of the conkeror package uses xulrunner-1.9 if present,
> else xulrunner-1.9.1.)

IMHO, alternatives are not the proper way to handle this.
Technically, if you use the xulrunner stub for pure xul applications,
or the xpcom standalone glue for "native" applications (which you
should already be), and you have both versions installed, and your
application correctly tells the stub or glue the versions it supports,
then any version can be used.
Note that currently, the upstream code handling that is quite broken,
and only considers the first entry in the directory /etc/gre.d (or
~/.gre.d) that matches the required versions. This means that if both
1.9 and 1.9.1 are suitable, and somehow 1.9 comes first in the directory
listing, it will be the one used. I do think the most suitable (biggest
version, probably) should be used. Definitely not a random one depending
on a directory entry ordering.
In any case, you can set the MOZ_GRE_CONF environment variable to the
full path of the file in /etc/gre.d containing info about the version of
xulrunner you'd want to use.

Mike