2015-10-27 18:45 GMT+01:00 Florian Weimer <f...@deneb.enyo.de>:

> * Jérémy Lal:
> > But nodejs isn't actually the only rdep, you should check libv8-dev
> > rdeps as well: weechat, uwsgi, mongodb, osmium, plv8.  The mess came
> > from lack of v8 LTS and version ABI support.  Now that nodejs LTS is
> > just doing that work, a shared v8 would benefit from it.
> Hi Jérémy,
> we certainly won't object to any reduction in bundling.  But it seems
> I lack sufficient context.  What is the controversial aspect of this
> proposal?  That the required work on other reverse dependencies may
> make it un-implementable?
nodejs 0.10 in stable is using libv8-3.14.
Both packages had/have no long term support from upstream.
Also upstream nodejs wasn't trying to keep any sort of abi compatibility
("a mess" because i couldn't come up with a good idea to cope with it).

Now upstream nodejs >= 4 minds abi breakage, provides
(which is 46 at the moment) and debian nodejs 4.2.1 package provides a
nodejs-abi-<process.versions.modules>, and c++ modules will depend on that
virtual package (only node-iconv at the moment).
This means nodejs abi is tracked by upstream, and they commit to not change
it during the LTS period.
Also when it changes it will be simpler to rebuild all debian packages
affected by
that change, thanks to the dependency on the virtual package (thanks to

What's also new is that upstream nodejs will support version 4.2.x for
three years,
starting this month, and will backport security patches to their copy of v8
during that time.
I say it's a nice opportunity for reverse dependencies of v8, and i think
nodejs 4.2 upstream tarball as a source for v8 4.5 during that time will be
straightforward way to maintain a libv8 debian package.

Pkg-javascript-devel mailing list

Reply via email to