Code copy of older Mozilla code

Moritz Muehlenhoff jmm at inutil.org
Sat Mar 1 12:22:00 UTC 2014


severity 733496 wishlist
tags 733496 wontfix
thanks

Hi Mike/Emilio,

On Thu, Feb 27, 2014 at 12:06:23PM +0900, Mike Hommey wrote:
> On Wed, Feb 26, 2014 at 08:53:32PM +0100, Emilio Pozuelo Monfort wrote:
> > Hi Moritz,
> > 
> > Laurent spoke to Mike regarding this and Mike said he was thinking/planning on
> > dropping libmozjs packages from src:iceweasel (please correct. The only possible
> > alternative is to have a code copy as a separate source package (as we have done
> > with mozjs and now with mozjs17). Note that depending on mozjs from iceweasel
> > would have a big impact on stable when iceweasel is upgraded.
> 
> Indeed. The js API and ABI are both highly unstable, so having it
> shipped by iceweasel ensures all rdependencies using it will suffer. The
> same can be said of xulrunner, and I'm seriously considering killing the
> package too (in fact, I'm also pushing to kill it upstream, providing
> the functionality itself off firefox). As of current packaging, libmozjs
> is gone from the iceweasel 29 package on mozilla.debian.net. I'm tempted
> to make it go away as soon as 28.

I agree with no longer providing xulrunner-dev. The approach used to be right in
the lenny days when we only need to fix src:xulrunner to address icewasel/icedove
and iceape, but with the yearly rotation there's clearly too much churn for
the reverse deps.

As for libmozjs*: We can treat them as unsupported with security updates. Every 
application build-depending on libmozjs* can assess whether this poses a problem,
but I think it's acceptable for most. 

couchdb
edbrowse
dehydra
gxine
0ad
libproxy
mediatomb
gjs
oolite
dehydra

The only reverse dep which seems to be exposed to untrusted Javascript from web sites
is apparently edbrowse, but this seems like an acceptable risk...

Cheers,
        Moritz



More information about the pkg-gnome-maintainers mailing list