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

Axel Beckert abe at
Fri Jul 10 21:43:56 UTC 2009


On Wed, Jul 08, 2009 at 11:08:22PM +0200, Mike Hommey wrote:
> > 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.

Ok, sounded to me on backports-users as if were weeks... Then I don't
seem to have missed a lot. :-)

> > 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),

I call either "xulrunner-1.9 path/to/application.ini" or
"xulrunner-1.9.1 path/to/application.ini". Works fine(*).

My idea was to just call "xulrunner path/to/application.ini" and which
version of xulrunner is called depends on the symbolic link in

I must admit that this obviously can go wrong if this symlink points
to an incompatible version xulrunner (e.g. 1.8 in case of conkeror).
Didn't come to my mind when I wrote my previous mail.

(*) The other method of installung xulrunner applications I know is to
    copy (symlinking is said not to work) xulrunner-stub to the
    appliation's directory and rename it. This obviously doesn't work
    out for packaging xulrunner appliations.

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

Ok, that doesn't sound very nice.

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

Doesn't seem to work if I call

env MOZ_GRE_CONF=/etc/gre.d/1.9.1.system.conf xulrunner-1.9

Or does that only work when xulrunner-stub is used?

P.S. to Mike: Thanks for cross-posting your xulrunner 1.9.1 warning
     	      also to this list. Read it here first. :-)

	Slightly confused about how xulrunner really works, Axel
Axel Beckert - abe at, abe at -

More information about the pkg-mozilla-maintainers mailing list