Can anyone on the Node.js team review this pull request and help get it into v26 LTS?
https://github.com/nodejs/node/pull/63270
It’s blocking Kitten from moving to Node 26. (And not just us.)
0 Boosts
0 Likes
@david_chisnall Thanks. If you get a moment can you comment on the issue/PR as I don’t think anyone’s raised that point there.
@david_chisnall PS. If not, happy to copy it in and/or link to your post for you if that’s ok.
@aral The issue seems to be that Debian & Ubuntu don't pull libatomic as a dependency when node.js is installed or updated.
A Debian/Ubuntu dependency problem should not be "fixed" upstream, that's a Debian/Ubuntu package maintainer problem.
Furthermore, the proposed patch hardcodes a binary which is bound to break things and cause problems. That patch wouldn't fly even if this was a node.js problem to begin with, which it's not.
@chaekyung @aral I was wondering why it's this being done in node repo and not as a fix to the distro package dependency graphs? 🤯
@nCrazed @chaekyung Well then they should look into a different fix: basically, Node.js images are broken out of the box on those platforms when they previously weren’t.
@aral @nCrazed As I already told you:
"A Debian/Ubuntu dependency problem should not be "fixed" upstream, that's a Debian/Ubuntu package maintainer problem."
NO, the Node.js developers should _not_ look into a "different fix". IT'S NOT THEIR PROBLEM.
Similarly, if Mozilla Firefox is broken on Linux Mint the that's a Linux Mint problem which should be fixed by Linux Mint, not Mozilla.
I honestly find this whole discussion to be hugely embarrassing. Package dependency management is such a basic concept, and it's so obvious that it's a distro responsibility, not a upstream issue. Adults who can't grasp this concept shouldn't work in or anywhere near IT, I'm not even sure they are mentally qualified to clean a IT departments toilets.
@chaekyung Do feel free to fuck off at your leisure.
@aral @chaekyung has *anyone* Rachel out to the respective distro package maintainers abouy this? How is that not the first, or at most second, step? 🤨
@aral
That looks dangerous. libatomic (hey, I wrote that!) is provides fallback routines for CPUs that don't have atomic operations of a specific size. It's normally provided by a shared library because statically linking it can easily end up with two different copies of the same symbols, which will use different locks. If you dynamically load a plugin that links to the platform's standard version of this, then you can end up with some atomic operations not actually being atomic. Debugging this is incredibly difficult because you get intermittent, rare, data corruption.