Skip to content

Conversation

@manuschillerdev
Copy link

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Motivation and Context

It is common to have gnu-tar alongside other GNU tools installed and aliased for compatibility reasons.
However, this breaks the current make build. The following error happened when GNU tar tried to extract the pkg Payload (which is cpio+gzip, not tar) during make all > install target, extracting pkg Payload to bin/ and libexec/:

gtar: This does not look like a tar archive
gtar: Skipping to next header
gtar: Exiting with failure status due to previous errors

The build succeeded, the pkg was created, but the extraction silently failed, leaving bin/container missing.

The proposed fix uses BSD-only binaries (no GNU equivalents that are commonly aliased), making the Makefile more portable.

Why gunzip | cpio instead of tar:

  • macOS pkg Payloads are gzip-compressed cpio archives, not tar
  • BSD tar (macOS default) can read them because libarchive auto-detects formats
  • GNU tar (gtar) cannot

Testing

  • Tested locally
  • Added/updated tests
  • Added/updated docs

@Ronitsabhaya75
Copy link
Contributor

@manuschillerdev This looks good, but switching the cd from temp_dir to DEST_DIR concerns me. What if temp_dir is relative? The old cd $${temp_dir} made the Payload reference safe. Could you verify temp_dir is always absolute, or restructure the pipe to be defensive?

@manuschillerdev manuschillerdev force-pushed the fix/makefile-compatibility branch from 908a1df to f179309 Compare January 11, 2026 10:00
macOS pkg Payloads are gzip-compressed cpio archives. BSD tar (default on
macOS) handles these via libarchive auto-detection, but GNU tar cannot.

Using pax avoids this issue as it's a native macOS tool that handles
gzip+cpio archives directly and is unlikely to be aliased.
@manuschillerdev manuschillerdev force-pushed the fix/makefile-compatibility branch from f179309 to f06c20b Compare January 11, 2026 11:37
@manuschillerdev
Copy link
Author

@Ronitsabhaya75 thx for the review!

I landed on pax as a final suggestion. It is a single cmd, has proper error propagation, is native to macOS, and is unlikely to be aliased. Would that be fine with you?

 # changes cd order, but safe since mktemp always returns absolute path 
 (cd "$(DEST_DIR)" && pax -rz -f $${temp_dir}/Payload)

other options considered, but rejected (see reasons in comments)

 # masks gunzip errors (pipe returns last command's exit status)
 (cd $${temp_dir} && gunzip -c Payload | (cd "$(DEST_DIR)" && cpio -idm))

 # not POSIX (bash-only)
 (cd $${temp_dir} && set -o pipefail && gunzip -c Payload | (cd "$(DEST_DIR)" && cpio -idm))

 # extra temp file, more complex than original
 (cd $${temp_dir} && gunzip -c Payload > Payload.cpio && (cd "$(DEST_DIR)" && cpio -idm) < Payload.cpio)

@manuschillerdev manuschillerdev changed the title fix: use cpio for pkg payload extraction to support non-BSD tar environments fix: use pax instead of tar for pkg payload extraction Jan 11, 2026
@Ronitsabhaya75
Copy link
Contributor

@manuschillerdev Great analysis! I like the pax solution it's cleaner and you're right that it avoids the pipe error masking issue. The mktemp absolute path guarantee makes sense too. Appreciate the thorough explanation of the alternatives you considered. This looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants