Re: gnome-spidermonkey?

[Frederic Crozat <fred crozat net>]

2010/12/13 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.

Unless you ensure rpath are done to a "stable" path (for instance
/usr/lib/xulrunner-1.9.2 which is a symlink to latest installed
release of 1.9.2.x).

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

Don't build FF in jhbuild, use the one provided by your distribution.

-- 
Frederic Crozat