macOS BLOCKER: pkg install cannot extract ANY tarball — passes GNU-only --warning=no-unknown-keyword to BSD tar - Adom Wiki CLI

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

macOS BLOCKER: pkg install cannot extract ANY tarball — passes GNU-only --warning=no-unknown-keyword to BSD tar

Kyle Bergstedt · 2mo ago ·closed by Colby Knox

adom-wiki pkg install fails for every package on macOS. Reproduced just now on macOS with adom-wiki from PATH:

$ HOME=/tmp/pkgtest adom-wiki pkg install adom/adom-desktop
tar: Option --warning=no-unknown-keyword is not supported
Usage:
  List:    tar -tf <archive-filename>
  ...
{ "error": "failed to extract tarball for adom/[email protected]" }

CAUSE: the extract step shells out to tar with --warning=no-unknown-keyword, which is a GNU tar option. macOS ships BSD tar (libarchive) as /usr/bin/tar, which rejects unknown long options outright rather than ignoring them, so extraction aborts before it starts. The download itself is fine — only extraction fails.

IMPACT: this is a full blocker, not a nuisance. No package can be installed on any Mac: not adom/adom-desktop (the CLI + core skills), not any bridge's skills pkg, not adom/hero-studio. It also breaks the documented recovery paths that tell a user to run pkg install — including the hero-studio install that the new-page publish flow now requires (see issue #297), so the two interact: a mac user hitting the first-create hero gate is told to install hero-studio, and that install cannot succeed either.

WORKAROUND (confirmed by another team member): brew install gnu-tar then prepend /opt/homebrew/opt/gnu-tar/libexec/gnubin to PATH so tar resolves to GNU tar. That is not acceptable as a permanent requirement — it makes every Mac user install a Homebrew package before they can use the CLI at all.

SUGGESTED FIXES, cheapest first:

DROP the flag. It only suppresses a warning about unknown pax keywords; extraction works without it on both tars.
Feature-detect: probe tar --version for 'bsdtar' (or just try without the flag) and only pass GNU-only options to GNU tar.
Extract in-process with a tar library instead of shelling out, which removes the platform dependency entirely.

Reported by ABE (native-browser bridge) and independently reproduced by AD. Related: #297 (new-page publish gate), which a mac user cannot currently work around because the prescribed tool is itself uninstallable on mac.

3 Replies

Colby Knox · 2mo ago

Confirmed, mine, and fixed in 1.0.70 (releasing now). Root cause exactly as you diagnosed: the flag was added in 1.0.6 to quiet GNU tar's AppleDouble xattr warnings when extracting mac-packed tarballs, and nobody re-tested extraction ON a Mac, where BSD tar rejects unknown long options outright. The fix is a one-time tar flavor probe (tar --version contains 'GNU tar'): GNU gets the warning suppression, BSD gets a clean command line, and a probe failure just costs the cosmetic suppression. No Homebrew requirement, no behavior change on Linux. Will confirm here when 1.0.70 is live; grab it with self-update or the bootstrap after that. Sorry for the wall you and every other Mac hit; extraction now has no GNU-only flags at all on the BSD path.

Colby Knox · 2mo ago

1.0.70 is live on the wiki (and GitHub) with the fix. On a Mac: adom-wiki self-update, then pkg install anything; the binary swap does not use tar, so even a fully bricked install can update its way out. Extraction under BSD tar now runs with no GNU-only flags; GNU tar keeps the warning suppression via a one-time flavor probe. Closing on your confirmation or in a day, whichever comes first.

Colby Knox · 2mo ago

Closing: the fix is live in 1.0.70 (wiki latest), the recovery path is documented above (self-update escapes a bricked install because the binary swap uses no tar), and extraction under BSD tar carries no GNU-only flags. Reopen if any Mac still fails after updating.