{node_abi}-{platform}-{arch}.tar.gz filename format doesn't work with SunOS/Solaris/SmartOS/OmniOS

[dekobon]

Due to an unfortunate history of the SunOS derivative operating systems. The uname -s (kernel name / platform name) returned on Solaris family operating systems all return sunos. The reality is that you would be hard-pressed to find a Solaris box to do a build on in order to create a binary that was compatible with Solaris 11 / OpenSolaris / SmartOS / Illumos / OmniOS, etc.

Would there be a way to add an additional field of information like distro or kernel version to allow binaries to be distinguished further? As it stands now, making downloadable binaries for the OpenSolaris derivative OSes is impossible to do an a way that is universally compatible.

In fact, this is a problem with Linux as well. Even though the Linux system call table remains fairly stable, there have been breaking changes from time to time and there is no guarantee that there will not be in the future, so capturing another metric to indicate the api compatibility level of the kernel would be a good idea.

To add some additional context about what I'm trying to accomplish practically - I want to save time by skipping the compilation step in a SmartOS 5.1 zone for the sqlite3 npm module. In Linux, the module uses node-pre-gyp's binary functionality to download a binary off of s3 and use it. However, I can't just create a binary and offer it to the project because the SmartOS (as with all SunOS derivatives) platform is identified by the string sunos - which means that the binary could be anything from actual SunOS to Solaris 11. Essentially, the platform identifier doesn't give any insight into the system call table compatibility across kernel versions (which is the same for Linux).

[Mithgol]

Do you have some exact idea of a better identifier in mind?

[Mithgol]

(I get it that package_name should allow something like {node_abi}-{platform}-{kernelid}-{arch}.tar.gz instead of a simpler {node_abi}-{platform}-{arch}.tar.gz, but what exactly would that {kernelid} be?)

[Mithgol]

Ideally, and in the future, if a good enough kernel identifier works well on the node-pre-gyp level, then it should be further proposed to Node.js developers as a new feature, a new field of Node's process object.

[xzyfer]

We (the node-sass team) ran into a similar issue trying to support Alpine. It reports itself as linux but doesn't always work with typical glibc binaries.

We ended up with {platform}_{platformvariant}-{arch}-{abiversion}_binding where platformvariant was musl on Alpine.

sass/node-sass#1836

[saper]

We can have different libc ABIs (glibc2 vs musl), different stdc++ ABIs (clang vs GNU vs various versions of Visual Studio) and of course node ABI that includes V8. Additionally there are problems with bundled/unbundled OpenSSL and libuv, but that would be a real can of worms...