Some thoughts about the handling of xulrunner-1.9.1 et al.
Axel Beckert
abe at deuxchevaux.org
Fri Jul 10 21:43:56 UTC 2009
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.
> 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?
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 deuxchevaux.org, abe at noone.org - http://noone.org/abe/
More information about the pkg-mozilla-maintainers
mailing list