{node_abi}-{platform}-{arch}.tar.gz filename format doesn't work with SunOS/Solaris/SmartOS/OmniOS
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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