[Pkg-javascript-devel] Bug#904274: Bug#904274: nodejs: Debian nodejs is not ABI-compatible with upstream nodejs

[Elana Hashman]

On 2018-07-22 16:29, Jérémy Lal wrote:
> 
> You lost me a little here.
> From what i understand, there are only two general solutions:
> 1.a build from source at install time

Yup, by building from source, you typically avoid any ABI compatibility 
issues by surfacing them at build time.

> 1.b build from source in an OS package (which is later distributed as 
> binary, or not)

This may not ensure ABI compatibility, though. Suppose I build package 
node-my-native-extension v1.0 against node 8.x. If this package declares 
a Depends on nodejs (>= 8) and the user installs node 10.x with 
node-my-native-extension == 1.0, it's not necessarily ABI-compatible, 
but the OS packaging relationship doesn't reflect that. We ensure ABI 
compatibility with language-specific policy and supporting technology: 
for example, we place the extension built against node 8.x in 
/usr/lib/node/8.x/my-native-extension folder instead of 
/usr/lib/node/my-native-extension, or we compile it in a postinst script 
to ensure 1a, or we include symbols for both 8.x and 10.x ABIs in node, 
etc. And that solution must be consistent across all native node Debian 
extensions to ensure compatibility.

> 2. distribute a contained (be it statically compiled or smarter 
> solutions like flatpak), heavy, blob

Yes, I think statically compiled native node extensions fall in this 
category, and compatibility is also enforced by policy and technology. 
In node's case, it sounds like the version of the NODE_MODULE_VERSION is 
checked for compatibility. Currently, Debian exports the same version of 
this symbol as upstream does, but our ABI is not compatible with 
upstream because we export the wrong OpenSSL symbols. This is the crux 
of my bug report.

To fix this, we could:

1) Patch the symbol version to differ from upstream, declaring 
incompatibility with all prebuilt native node extensions (i.e. create a 
Debian-specific ABI)
2) Leave it alone but attempt to provide ABI compatibility (i.e. make 
the Debian ABI match upstream better)

I prefer #2 because #1 is a lot of work :) We will get #2 for free in 
Debian when node gets upgraded to 10.x.

> In-between will break at some point, in unpredictable ways...
> Will it not ?

Potentially, yes. This is what policies like manylinux (linked as PEP 
513 in my last email) intend to address. I am a maintainer of the 
"auditwheel" tool which checks statically compiled Python binaries to 
ensure that the symbols present in audited packages are widely supported 
by many base Linux systems. This provides a good safety layer, but of 
course incompatibilities arise from time to time. We try to fix them 
quickly! I'm unfamiliar with how node is addressing things like this (or 
whether they have an ABI policy), but I'd love to start a conversation 
about it.

Cheers,

- e