Parch

source: handbook ch. 38

Package submission

Parch reviews every package that enters its repositories. The documented channel is email review; distribution happens through the Void (testing) and world (stable) repositories.

Before you submit

  • Builds in a clean chroot, not just your system (building packages).
  • namcap reports no warnings you cannot justify.
  • Install, upgrade, and remove cycle tested (testing and validation).
  • Real sha256sums (never SKIP except for VCS sources).
  • License present and correct.
  • Naming follows the conventions.
  • .SRCINFO generated with makepkg --printsrcinfo.

The submission email

Send to contact@parchlinux.com with a subject line in one of these forms:

[SUBMISSION] New package: <name>
[SUBMISSION] Update to <name> (version bump)
[SUBMISSION] Takeover of <name>
[SUBMISSION] Removal request: <name>

The body should contain:

  1. Upstream information: project URL, what it does, why Parch users want it.
  2. The complete PKGBUILD, inline.
  3. The .SRCINFO, generated by makepkg --printsrcinfo.
  4. Install script and desktop file if the package ships them.
  5. Testing evidence: the commands you ran and their outcome (build in chroot, install/remove cycle, the app launching).
  6. Licensing note: the license and where its text lives upstream.

Review

Review is manual and informal; timelines depend on maintainer load (the handbook describes initial response in days, not hours). Reviewers look for:

  • Correct metadata: architecture, dependencies (minimal, no duplicates), license, checksums.
  • Files in the right places, no collisions with existing packages.
  • Install scripts that only do what pacman hooks cannot.
  • Whether the package belongs in Parch at all, or should go to the AUR. Parch repos are for software that serves Parch users specifically.

You will get feedback as replies to your email; iterate until accepted.

From acceptance to users

Accepted packages are built and published to the Void repository for testing, then promoted to world. Users on testing help catch what CI cannot. Promotion to world makes the package appear for every user on the next pacman -Syu.

# A tester opts in:
$ sudo pacman -Syu   # with [void] enabled in pacman.conf

AUR as an alternative

Packages useful to the wider Arch ecosystem belong in the AUR instead: git-based, immediate publication, community-maintained. Submit there by pushing to ssh://aur@aur.archlinux.org/<pkgname>.git with a PKGBUILD and .SRCINFO.