Packaging for Parch

Parch GNU/Linux uses the pacman package system and the PKGBUILD package format it inherited from Arch. Everything on a Parch system, from the kernel to the first-party desktop tools, is delivered as a .pkg.tar.zst archive that pacman can install, upgrade, and remove atomically. This section covers the whole packaging pipeline: reading and writing PKGBUILDs, building with makepkg, validating and testing, submitting your package by email, and maintaining it afterwards.

Anatomy of a package file

A package is a compressed tar archive. You can list its contents without installing it:

Inspect a package

$ tar -tf parch-example-1.4.2-1-x86_64.pkg.tar.zst
.PKGINFO
.MTREE
.INSTALL
usr/
usr/bin/
usr/bin/example
usr/share/
usr/share/licenses/
usr/share/licenses/parch-example/LICENSE

Member	Purpose
`.PKGINFO`	Machine-readable metadata: name, version, dependencies, build options. Pacman reads this to resolve dependencies.
`.MTREE`	Gzipped inventory of every file in the package with sizes and SHA-256 digests. Pacman uses it to verify installed files with `pacman -Qkk`.
`.INSTALL`	Optional shell script with `pre_install`, `post_install`, `pre_upgrade`, `post_upgrade`, `pre_remove`, and `post_remove` hooks. Present only when the PKGBUILD sets `install=`.
`usr/`, `etc/`, …	The actual file tree that pacman extracts onto the system.

Everything outside the file tree is metadata generated by makepkg from the PKGBUILD, so a good package starts with a good PKGBUILD.

The three package origins

Every package on a Parch system comes from one of three places:

Origin	What it is	Examples
Upstream Arch	Packages taken unmodified from the Arch repositories (`core`, `extra`, `multilib`). Parch tracks Arch and does not rebuild these.	`linux`, `plasma-desktop`, `firefox`
Parch-modified	Upstream software rebuilt with Parch patches, defaults, or branding.	`calamares-parch`, themed session packages
Parch-exclusive	Software written for Parch that exists nowhere else.	`parch-welcome`, `parch-update`, Pastor (the Parch Store), `mirrorman`, `gamehub`, `pordle`, PKM

Parch-exclusive and Parch-modified packages carry the parch- name prefix so they are easy to spot with pacman -Ss. The full naming rules are on the naming and versioning page.

The repository layer

Binary packages are distributed through two Parch repositories, listed in /etc/pacman.conf before the upstream repos:

/etc/pacman.conf (repository entries)

[void]
SigLevel = Optional TrustedOnly
Server = https://raw.githubusercontent.com/parchlinux/void/main/x86_64/

[world]
SigLevel = Never
Server = https://github.com/parchlinux/world/raw/refs/heads/main/x86_64/

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

world (github.com/parchlinux/world) is the stable repository. It carries all Parch-exclusive and Parch-modified binaries and is enabled on every installed system.
Void (github.com/parchlinux/Void) is the testing repository. New packages and updates land here first and move to world after community testing.

The packaging pipeline

A package travels this path from your editor to user systems:

Write the PKGBUILD: metadata, sources, checksums, and the four build functions.
Build locally: makepkg downloads sources, compiles, and produces the .pkg.tar.zst.
Validate and test: namcap, a clean chroot build with pkgctl build, install/upgrade/remove checks.
Submit by email: contact@parchlinux.com with the PKGBUILD, .SRCINFO, and test evidence.
Review: the team checks naming, licenses, dependencies, and packaging quality.
Publish to Void: accepted packages appear in the testing repository as binaries.
Promote to world: after community testing, the package becomes stable.

The source of step 1 and 2 is the PKGBUILD itself, not a binary blob: even though Parch distributes binaries, everything reaches users as a reviewed, reproducible recipe. If you are packaging your own application, start from the application development section for the build side and come back here for distribution. Packages that should appear on an ISO are wired in through the package list, see ISO building for that integration.

In this section

PKGBUILD reference

Every variable, the four functions, checksums, and a complete worked example.

Building packages

makepkg workflow, corrected flags, clean chroot builds, signing, local repos.

Example packages

Four complete PKGBUILDs: CLI, desktop app, systemd service, split library.

Naming and versioning

Parch naming rules, pkgver/pkgrel/epoch semantics, VCS versions.

Testing and validation

Chroot builds, file collision checks, hook testing, metadata validation.

Submission

The email workflow, .SRCINFO generation, what reviewers look for, promotion.

Maintenance

Update workflow, soname rebuilds, security response, orphaning, removal.

Continue in Packaging

PKGBUILD referenceEvery PKGBUILD variable, the four build functions, checksum arrays, source renaming, and a complete example for a Rust CLI application.Building packagesThe makepkg workflow: install the toolchain, fetch PKGBUILDs with pkgctl, corrected makepkg flags, clean chroot builds, GPG signing, and a local test repository.Example packagesFour complete PKGBUILDs to copy from: a Rust CLI, a GTK/Python desktop app, a systemd service with sysusers and tmpfiles, and a split library.Naming and versioningParch package naming rules, the pkgver/pkgrel/epoch version model, VCS package versions, and what to bump when.Testing and validationThe pre-submission test plan: static checks, clean chroot builds, content audits, install/upgrade/remove cycles, collision and hook testing, metadata validation, and license compliance.Package submissionThe documented path from a working PKGBUILD to the world repository.Package maintenanceKeeping packages healthy after the first upload: updates, security, and handover.