Quoting Robie Basak (2021-10-11 12:39:00)
> I think it's worth noting what happened with nodejs in Bionic:
> Summary: nodejs incorporated the version of openssl it gets built with
> into its ABI, causing incompatibility between binary modules built in
> different places if they mismatch, contrary to ecosystem expectations.
> Upstream therefore considers the openssl version that must be used
> "locked" for a particular nodejs version. But if we use the version
> upstream wants, and that differs from our "default" version, then the
> resulting co-installability conflict between the two -dev packages
> results in users complaining about that instead.
> It might be worth someone looking into this early in order to try to
> avoid or mitigate a recurrence of this kind of issue.
(my apologies, this mail will likely contain quite a few links)
I looked a little bit into this, and as of 8 hours ago, the embedded copy
of OpenSSL has been updated to version 3.0.0. They have an open issue
tracking the OpenSSL 3.0 support situation, and their technical
committee has a document specifiying which OpenSSL release is supported
for a given NodeJS version.
According to this comment it seems they don't plan on supporting
OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have
its first release next week according to their release schedule.
Sadly, the new 17.x branch isn't planned as an LTS one.
Looking inwards, we currently ship a NodeJS version based on the 12.x
branch, and Debian seems to be planning a transition towards the 14.x
branch. None of which support OpenSSL 3.0.
Unless I'm missing something, I see the following options, in no
(a) Remove NodeJS from the archive. Had to be mentioned, but I don't
think it's realistic ;-)
(b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1
in the archive via a compat package.
(b') The same but using the embedded copy of OpenSSL (if even possible?).
(c) Use NodeJS v17.x in JJ (when it's out), with OpenSSL 3.0. This would entail
doing the transition on our own, and it basically would be EOL two
months after the JJ release.
(d) Track the NodeJS master branch in JJ and update NodeJS to the official
version 18.0 a few days after our release of 22.04.
(e) Use 16.x + OpenSSL3 patches. I'm not entirely sure whether this
would create the same issues as mentioned by Robie, as the support
for a linked 3.0.0 is documented in .
I feel like (b) is our safest bet. If we go this route, we'll want to
make sure that libssl-dev and libssl1.1-dev are coinstallable, as it was
apparently a painpoint in the previous OpenSSL transition.
I welcome any other options or perspectives on the issue :)
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel