mapbox / mapbox/node-pre-gyp

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

Open
#251 5 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
1.2k
Forks
271
Avg merge
23h 40m
Merged PRs (30d)
2

Description

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](http://unix.stackexchange.com/a/271156/1953) 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](https://en.wikipedia.org/wiki/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).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named in the issue. Start by tracing how the `{node_abi}-{platform}-{arch}.tar.gz` filename and the `uname -s` platform value are produced; done would require an agreed way to distinguish SunOS derivatives and kernel compatibility without breaking existing binary downloads.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, node.js
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.