Re: gnome-spidermonkey?

[Owen Taylor <otaylor redhat com>]

On Sat, 2010-12-11 at 11:23 +0000, Maciej Piechotka wrote:
> On Sat, 2010-12-11 at 08:33 +0100, Frederic Crozat wrote:
> > 2010/12/11 Maciej Piechotka <uzytkownik2 gmail com>:
> > > On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote:
> > >> Basically, I want us to be decoupled from this; there are conceptually
> > >> actually 4 layers.
> > >>
> > >> NSPR <- spidermonkey <- xulrunner <- firefox
> > >>
> > >> Where "<-" is depends on.  Right now at least Fedora ships like:
> > >>
> > >> NSPR <- (spidermonkey xulrunner firefox)
> > >>
> > >> Where () is "tightly coupled", meaning that gjs and gnome-shell are
> > >> tightly coupled to firefox.
> > >>
> > >> Having a separate xulrunner as a project hasn't really worked - it's a
> > >> *huge*, enormous codebase.  Spidermonkey on the other hand has always
> > >> nominally supported being built seprately; it has its own configure
> > >> script, etc.
> > >
> > > Probably better way would be to work on parallel installation of
> > > xulrunner and/or spidermonkey then forking. I.e. if needed there should
> > > be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at
> > > the same time.
> > 
> > This is already possible for xulrunner in most distributions.
> > 
> Then probably the problem is Fedora itself then coupling. Since
> otherwise the gnome-shell/gjs are coupled to particular branch of
> xulrunner if I understand correctly. 

Can't really follow this. There are two different strategies I know of
for building other packages against Firefox:

 Use rpaths in the binaries. GNOME Shell needs to be rebuilt for every
 minor release of Firefox whether the ABI changes or not.

 Put the libmozjs.so in the system linker paths using 
 /etc/ld.so.conf.d/

Fedora takes the second approach. Neither approach gives you transparent
parallel installs of different ABI-guaranteed versions of Spidermonkey
and:

> I guess update xulrunner 1.9.x -> xulrunner 1.9.(x+1) does not require
> code changes

Upstream doesn't make this guarantee as far as I know. (Yes, changes
within 1.9.x have been small compared to the difference between 1.9.x
and 2.0)

> so the problem can be derefered to distributions (updates,
> updating fx/gjs/gnome-shell when ABI changes for example due to inlining
> etc.).

While certainly the fact that security updates for Firefox could require
code changes to GNOME Shell is a problem, and yes, parallel installation
can get around that at the expense of extra disk space usage and
packaging complexity, it's not the only point.

 We need a smallish amount of code. The complete Firefox build
   in the jhbuild takes a long time.

 We want to have a common version of Spidermonkey for all
   distributions  shipping GNOME rather than wildly divergent
   versions.

- Owen