hi ! Nodejs c++ addons (modules) in buster are built using libnode-dev - a great improvement over previous "situation". However upstream libnode embeds its dependencies, whereas almost all debian libnode dependencies are shared. Modules authors expect a given node ABI to offer the same versions, or versions abi-compatible with, of these dependencies: uv, v8, openssl. In the case of distributions, upstream acknowledged the fact distributors were building nodejs against shared libraries, thus the versions might now be the same, breaking their module ABI contract. So upstream started working on a registry to keep track of ABI changes mandated by distributors conditions. It's a work-in-progress but it's due: https://github.com/nodejs/node/blob/9adf1fbe/doc/node_module_versions.json#L6
In Debian case, the api-break comes from openssl 1.1.1 where upstream used to embed openssl 1.1.0: [upstream view] (https://github.com/nodejs/node/issues/18770#issuecomment-456918214) [openssl discussion] ( https://mta.openssl.org/pipermail/openssl-project/2019-January/thread.html#1204 ) It happens that that api breakage has been reverted and is merged in openssl 1.1.1 stable branch: https://github.com/openssl/openssl/commit/37857e9b5258da148e5d3699b6acdf8787417eb2 If openssl releases this and the release goes to buster, then all is fine in nodejs land. If it doesn't, debian should ship libnode65, not libnode64, to make sure foreign node modules will be able to know they're not installed on a compatible version of libnode. The change in itself is trivial (just changing the soname) and should end up being an automated transition. However it's a special case that needs release team approval and coordination, between openssl and nodejs. Thanks for the feedback, Jérémy