Adding Spidermonkey 17esr to Raring

[Tim]

I guess this got lost in the flood of Rolling Release discussions....

Is there any reason why we couldnt have both versions of spidermonkey in the archive? It is simply not feasible to port all rdepends to the new
engine, and I guess most other upstreams (apart from gnome) arent going to start porting things until new engine is readily available in distros.

- Tim
 
On 28/02/13 12:33, Tim wrote:
> Hi,
>   Finally after about 2 years Mozilla are releasing a version of the standalone spidermonkey engine. This release is based off the engine from
> Firefox 17esr. It has taken quite a long time to get to this stage, and I was hoping it would happen earlier in the cycle, but I would still
> like to get this into raring if at all possible. My motivation for this is the great improvements it brings to gnome-shell.
>
> This release fixes a number of high impact issues including greater performance, greatly reduces memory leaks, and finally solves the long
> standing and quite common issue with Garbage Collection deadlocks. I ported gjs to this engine a few months ago and while it hasnt landed
> upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of gjs, one for each engine.  This new gjs is API compatible with 3.6,
> and in fact works great with gnome-shell 3.6, so essentially it would be great to bring these improvements into raring.
>
> There are big API/ABI breaks in this release compared to previous 185 release. Currently none of the other rdepends have been ported as far as I
> know, and its probably not realistic to get all of them ported this cycle. Mostly the porting is easy enough, however it does result in quite
> large diff's so would really want to be done upstream, as it would probably  be a nightmare to maintain these as Distro patches. Add to this
> CouchDB is fundamentally incompatible with this new release, due to their use of illegal javascript syntax (in 185 enforcement of this was
> optional) as a core feature of their user scripts.
>
> Given the above, replacing/upgrading the old package is simply not going to be feasible this cycle. I propose adding this new engine as an
> additional library, I discussed this on IRC a bit with seb128 and chriscoulson, however they were unsure about whether this is something that
> could want to go ahead and suggested that I raise it here for more widespread discussion. Main issues raised were overall its a low priority but
> also some security concerns.
>
> Hopefully now with all the patches on their way into the upstream mozilla code-base, future releases will be more regular, they will be tracking
> the firefox esr releases. Although not really guaranteed just yet, it is planned for some  point releases over the life of each version.
> Probably issues with overlapping versions will continue to be a problem until the JS C API settles down, next release 24 will again break all
> rdepends.
>
> - Tim
>
>