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

[Elana Hashman]

On 2018-07-22 13:35, Jérémy Lal wrote:
> 
> Forwarded: https://github.com/nodejs/node/issues/21897

Yup, I've read through this as well.

> I agree there is a problem. I disagree the problem is only on the 
> distributor side.

I also agree that the problem isn't only on the distributor side, *but* 
I think it's easiest to push an effective short-term fix on the 
distributor side :)

I think the "correct" solution is to encourage node upstream to not 
bundle openssl symbols as part of their ABI, and to make an SSL API/ABI 
available as a separate, versioned, installable package (like how 
python-cryptography works). However, that sort of change is ABI-breaking 
and wouldn't be feasible until at least node 12.x, assuming that 
upstream devs accept this suggestion.

> The bug is reported upstream (see forwarded url above).
> Complaining that the distributor is not doing the right thing is a 
> wrong approach to the problem.
> You should instead try to understand more deeply the situation and see 
> what other languages do about that.

I am one of the manylinux maintainers as a member of the Python 
Packaging Authority, so I actually have a lot of experience with setting 
standards and writing software to ensure compatible native extensions on 
Linux! I have thought about this pretty deeply and can explain my 
reasoning below.

> TLDR; the pratical solution is to promote compilation of addons - which 
> is *straightforward* on debian/ubuntu/fedora and derivatives
> (you just need to explain which development packages must be 
> installed).

This is fair suggestion, but I think that there is significantly more 
lift to put this into motion. To accomplish this, I believe we'd have to 
go through the following steps:

1) Convince developers (upstream or downstream) to package their native 
dependencies for Debian
2) Sponsor native dep uploads to Debian
3) Convince end users to install and depend on the version in Debian

3) is going to be tough, because many folks who use Debian for 
development do not necessarily target a Debian production environment.

As another alternative solution, the way we do this in the Python world 
is:

1) Set a standard for the generic ABI ("manylinux"), while allowing for 
the development of downstream distro ABIs if desired
2) Convince developers to adopt the standard and provide tools to make 
it easy for them to build to the standard
3) Patch packaging tools (pip, for Python) to support the standard and 
detect the correct ABI for target installs

Either one of these options requires much more work by downstream Debian 
devs, upstream, *and* users versus just ensuring Debian's node ABI is 
consistent with upstream's.

This is why I advocate keeping Debian's ABI as closely matching upstream 
as possible, to reduce the overhead for Debian in maintaining a 
separate, incompatible ABI, and the extra development work and user 
education that will come along with that.

>> Ubuntu Bionic will need to patch their builddeps downstream to use the 
>> right version of openssl, and I'm going to comment on their bug along 
>> those lines. This is also an option for us in Debian, but given that 
>> we want to drop openssl 1.0.2 in buster, I'd suggest we could also fix 
>> this bug by upgrading node to 10.x, available in experimental, which 
>> depends on openssl 1.1.0 upstream.
> 
> Agreed ! As the main nodejs maintainer the only reason it is not 
> already the case is because i did not have time to handle it.
> I do that on free time, and it's a rare thing these days...

I totally understand, as a slammed maintainer myself. It would be great 
if we could recruit more folks to help you out with this.

As long as the plan in Debian is to upgrade to Node 10.x, when 10.x gets 
uploaded to unstable I'd consider this fixed. I marked this as 
"important" and not "serious" to reflect that I think it's important to 
get fixed by the next release but it doesn't need to be addressed 
immediately :) The biggest surface area is in Ubuntu, which I am trying 
to tackle with them directly.

- e