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
