xz support check in nvm.sh doesn't truly detect xz support in macOS

[DeeDeeG]

Hi folks,

I did a bunch of research on detecting xz support, in pursuit of adding a "system supports xz?" check to shadowspawn/nvh and tj/n.

The gist of it for Linux and macOS:

• On Linux, chances are very great that if the xz binary is on the system PATH, tar will support extracting xz-compressed tarballs.
  • Almost every Linux distro ships GNU tar. GNU tar added support for xz in version 1.22. Only very old distros ship with GNU tar older than 1.22, and those mostly don't have xz in the repos. It's therefore possible but very unlikely that a Linux machine has xz on the path but no support in tar.
  • nvm is basically already doing this check; It works great for Linux. If it works anywhere else, I would propose that that's pretty much just a coincidence or a happy accident.
• On macOS, xz compression/decompression relies on support that is baked into the libarchive/bsdtar that macOS ships with.
  • macOS started shipping new enough libarchive/bsdtar in OS X Lion (10.7)... but had xz support toggled off in pre-compile configuration, and didn't ship the underlying liblzma library that macOS would eventually use to support xz. macOS only ships xz support in macOS 10.9 or newer.
  • Starting in OS X Mavericks (10.9), OS X actually shipped libarchive/bsdtar with xz support toggled on, and shipped liblzma to use for compressing/decompressing xz archives
  • xz on the PATH is irrelevant (and a bit of a red herring!) for xz support in tar on macOS.
  • Checking just the libarchive/bsdtar version on macOS will mostly work, but you will get a false positive for OS X Lion and Mountain Lion (10.7 and 10.8, respectively).

I would recommend checking for macOS 10.9+ before enabling xz, and not checking for xz on the PATH on macOS at all. You can conveniently check the macOS version via command-line with sw_vers.

• https://scriptingosx.com/2017/11/on-the-macos-version/
• https://www.oreilly.com/library/view/macintosh-terminal-pocket/9781449328962/re104.html
• https://ss64.com/osx/sw_vers.html

---

Here are the main research findings from implementing this on nvh/n. (Scroll up/down in the issue for the whole convoluted research process, if you like!)

• Linux: XZ compression support shadowspawn/nvh#8 (comment)
• macOS: XZ compression support shadowspawn/nvh#8 (comment)

[ljharb]

Thanks, I'd be very appreciative of a PR that improves xz support detection.

[DeeDeeG]

Will work on a PR when I get a free moment to do so.

[DeeDeeG]

Hello again @ljharb, you mentioned me in shadowspawn/nvh#12. This is already the relevant issue, so I thought you might want to take another peek at this. Thanks.

Discussion in my earlier PR #2156 got really into the weeds, but it isn't really that complicated a problem, IMO. Just that I nerd out and give way too much detail lots of detail. If you have any questions I'll try to give shorter answers and move toward a solution. Not just mountains of theoretical considerations. :P

Best regards,

- DeeDeeG

[DeeDeeG]

If you like the checks that are used in tj/n I can try to recreate those at this repo.

• Linux with xz on the PATH? Fetch xz-compressed tarballs.
• macOS 10.9 or above? Fetch xz-compressed tarballs.
• Every other system: Fetch gzip-compressed tarballs.
  • For all platforms: xz usage is still contingent on checking that the Node version in question is known to have xz-compressed tarballs hosted for it.

[ljharb]

Oops, sorry :-) that bulleted list seems good to me.

[DeeDeeG]

While I was looking at this again, I tested the latest releases of the various BSDs in VirtualBox:

OS	uname -s	tar supports xz?
DragonFly BSD 5.8.1	DragonFly	✔️ yes
FreeBSD 12.1-RELEASE, GhostBSD 20.04.1, OPNSense 20.1, pfSense 2.4.5-p1	FreeBSD	✔️ yes
NetBSD 9.0	NetBSD	✔️ yes
OpenBSD 6.7	OpenBSD	❌ no

In all BSDs I tested the following was true:

• Where tar supported xz, xz was coincidentally on the PATH, and the file /usr/lib/liblzma.so existed.
• Where tar did not support xz, xz wasn't on the PATH, and /usr/lib/liblzma.so wasn't present.

I think the proper check on all BSDs is to look for /usr/lib/liblzma.so.

I can make this a separate issue and/or PR if you like. Or try to roll that into the same PR I'm already working on.

[ljharb]

Let's roll it into the one "make xz work properly" PR :-)