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 <uzytkown...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list