package info discrepancies

[mcandre]

Trying my best to dot all I's and cross all T's, towards a valid .pkg able to install.

Noticing some differences between PackageInfo files generated by pkgbuild vs. apple-flat-package.

% xcode-select --version
xcode-select version 2410.

To make diffing easier, I'm currently spoofing the generator version string. Planning to customize that once the package actually works.

For performance, serde-xml-rs elides indentation and line termination by default. Interesting enough, the UNIX file utility detects the long lines and emits a warning.

I do not know whether long lines trip up installer. Out of an abundance of caution, and in order to make debugging easier, I've taken the liberty of forcing XML indentation like:

let xml_emitter = serde_xml_rs::config::SerdeXml::new()
    .emitter(xml::writer::EmitterConfig::new().perform_indent(true));
let packageinfo_xml = xml_emitter.to_string(&packageinfo)?;
let mut packageinfo_file = fs::File::create(&packageinfo_pth)?;
packageinfo_file.write_all(packageinfo_xml.as_bytes())?;

pkgbuild:

% cat PackageInfo
<?xml version="1.0" encoding="utf-8"?>
<pkg-info overwrite-permissions="true" relocatable="false" identifier="test.bobsautoparts.hello" postinstall-action="none" version="1.0.0" format-version="2" generator-version="InstallCmds-860.14 (24G419)" install-location="/Library/bobsautoparts" auth="root">
    <payload numberOfFiles="5" installKBytes="1"/>
    <bundle-version/>
    <upgrade-bundle/>
    <update-bundle/>
    <atomic-update-bundle/>
    <strict-identifier/>
    <relocate/>
</pkg-info>

apple-flat-package:

% cat PackageInfo
<?xml version="1.0" encoding="UTF-8"?>
<PackageInfo auth="root" format-version="2" generator-version="InstallCmds-860.14 (24G419)" identifier="test.bobsautoparts.hello" install-location="/Library/bobsautoparts" overwrite-permissions="true" postinstall-action="none" relocatable="false" version="1.0.0">
  <payload numberOfFiles="3" installKBytes="1" />
  <scripts />
</PackageInfo>

Differences:

• Modern pkgbuild prefers the main XML node be named pkg-info rather than PackageInfo. Unclear at this time which name is preferable from the perspective of maximum backwards compatibility.
• pkgbuild denotes the encoding in lowercase (utf-8) rather than uppercase (UTF-8).
• pkgbuild reorders various XML node attributes. Hopefully the order is insignificant to Apple's XML parser.
• pkgbuild doubles the number of "files", excepting the root dot (.) directory. Its Bom generator creates AppleDouble dot underscore ([<parent>]/.../._<basename>) entries to accompany each ordinary payload file path. There appears to be no way to disable this, despite blogs claiming that xattr -cr <payload-source-dir> has an effect. Zoom is currently using an older pkgbuild version, which may explain why its Bom and Payload are missing these AppleDouble entries. macOS installer has no qualms with existing packages that lack these AppleDouble entries. Interesting that newer Xcode versions are forcing them. Online lore suggests it is a hack to account for some poorly designed CLI undocumented flags, and the fact that many archival components tend to silently ignore any Mac extended file system attributes on disk, that could end up missing from the final installation.
• pkgbuild forces some dummy XML nodes into the package info record:

<bundle-version/>
<upgrade-bundle/>
<update-bundle/>
<atomic-update-bundle/>
<strict-identifier/>
<relocate/>

And on the other hand, pkgbuild omits <scripts /> when no scripts are provided, versus apple-flat-package, which always includes that element.

There's also a stylistic thing about pkgbuild omitting any left padding spaces prior to the slash (/) in closing tag endings (e.g., <relocate/>). Versus apple-flat-package inserting an extra space there.

Recommend tweaking the apple_flat_package::package_info::PackageInfo to ensure that at least one of each of these dummy nodes is guaranteed to be generated, especially when the corresponding vectors are empty.

In practice, been getting the same tired cpio read error for days, with no respite.

2026-01-27 18:12:21-06 najma installer[63828]: install:didFailWithError:Error Domain=PKInstallErrorDomain Code=110 "An error occurred while extracting files from the package “hello-1.0.0.pkg”." UserInfo={PKInstallPackageIdentifier=test.bobsautoparts.hello, NSUnderlyingError=0x6000021cb210 {Error Domain=BOMCopierFatalError Code=1 "cpio read error: bad file format" UserInfo={destinationPath=/Library/InstallerSandboxes/.PKInstallSandboxManager/F42AF69B-AAEC-4D7F-894E-BF0853290956.activeSandbox/Root/Library/bobsautoparts, offset=911, type=BOMCopierFatalError, sourcePath=/Users/andrew/go/src/github.com/mcandre/pizzarat/examples/sh/.pizzarat/mac/hello-1.0.0.pkg, NSLocalizedFailureReason=cpio read error: bad file format}}, NSFilePath=/Library/InstallerSandboxes/.PKInstallSandboxManager/F42AF69B-AAEC-4D7F-894E-BF0853290956.activeSandbox/Root/Library/bobsautoparts, NSURL=file://localhost/Users/andrew/go/src/github.com/mcandre/pizzarat/examples/sh/.pizzarat/mac/hello-1.0.0.pkg, PKInstallPackageSHA256Digest=1708edfe230d7db693fd3ee02f7c638ee36f841ac03900c60d0bc30246646a6d, NSLocalizedDescription=An error occurred while extracting files from the package “hello-1.0.0.pkg”.}

I do not know whether these minor package info differences some how trigger macOS installer to fail. But I'm running out of reasons to explain why that happens.

Cleaning up some minor XML discrepancies would seem less important than fixing the cpio read errors.