On this page
Container
A package is a single file containing the package's payload and metadata. The on-wire form of a package is a Zstandard- compressed tar archive.
§3.1.1 File extension
The package file extension MUST be .peipkg. The full file is
a tar archive compressed with Zstandard.
§3.1.2 Tar format
The tar archive MUST conform to the POSIX pax interchange format (IEEE Std 1003.1-2017, Chapter 14).
§3.1.3 Compression
The tar archive MUST be compressed using the Zstandard format (RFC 8478).
The compression level is at the producer's discretion.
zstd is deterministic at all levels per RFC 8478;
producers MAY choose any level based on their build-time
versus decompression-time tradeoff. Higher levels (19 and
above, including --ultra) increase build time
substantially in exchange for smaller on-wire size; level
3 is a common default.
The compressed result is a single file with the .peipkg
extension. There is no intermediate .tar form on disk; the
producer's tooling produces the compressed form directly.
§3.1.4 Determinism
A package MUST be reproducible: given identical source inputs, identical build environment, and identical metadata (including the build timestamp recorded in the manifest), two independent producers MUST produce byte-identical package files.
To achieve this, the tar archive MUST follow these rules:
- Tar entries MUST be ordered lexicographically by path. Comparison is byte-for-byte over the UTF-8 path string.
- Every tar entry's modification time MUST equal the value
of
build.timestampin the manifest (§3.3). - Every tar entry's owner numeric ID and group numeric ID MUST be 0 (root).
- Every tar entry's owner name and group name MUST be the
string
root. - Tar entries MUST NOT carry extended attributes (xattrs). File security descriptors (PSD-004 §3.12) are applied at file-creation time via the kernel's file-creation interface (PSD-004 §11.2), supplied either by inheritance from the parent directory or from a manifest-declared override. See §3.4 for the SD application procedure. Other install-time attributes are applied via side-effect declarations (§4.3) or by higher-level integration mechanisms outside this specification.
- Tar entry permission bits MUST be
0777for every entry, with the setuid and setgid bits cleared (§3.4.6). - PAX extended header records, when present, MUST be in a
fixed canonical order:
pathfirst, thenlinkpathif present, then any other records sorted by record name lexicographically. - Tar header magic MUST be
ustar\0and version MUST be00. - Tar header
devmajoranddevminorfields MUST be 0 for all entry types defined by this specification (none of which are device entries). - Tar header padding bytes MUST be NUL (
0x00). - PAX global header records (typeflag
g) MUST NOT appear in the archive. - PAX extended header records (typeflag
x) MUST appear only when an entry'spathexceeds the ustar 100-byte limit (in which case apathrecord is emitted) or itslinknameexceeds the ustar 100-byte limit (in which case alinkpathrecord is emitted). Records with any other key MUST NOT be emitted.
§3.1.5 Streaming
A consumer MAY process the archive as a stream. The internal layout (§3.2) is designed so that metadata appears before payload, allowing a consumer to read the manifest and decide whether to continue without buffering the entire payload.
§3.1.6 Top-level structure
The compressed tar archive contains entries laid out according to the internal layout in §3.2. There is no additional outer wrapping (no enclosing directory, no multi-archive concatenation, no container metadata outside the tar entries themselves).