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

[Mike Hommey]

On Fri, Jul 10, 2009 at 11:43:56PM +0200, Axel Beckert wrote:
> Hi,
> 
> 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
> /etc/alternatives/.
> 
> 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.

Look at iceweasel, it does exactly that: symlinking xulrunner-stub and
name it firefox-bin (this name is for backwards compatibility). Note the
symlinking thing only works with debian xulrunner.
There is an extra thing iceweasel does, is to symlink the xulrunner path
to /usr/lib/iceweasel/xulrunner, which forces which xulrunner to use and
avoid the xulrunner-stub to look in /etc/gre.d.

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

It only works when the stub is used. Obviously, if you run xulrunner-1.9
directly, you want to use xulrunner 1.9 ;)

Mike