ALPM-SOURCE-REPO(7)

📦 version 0.13.0, in arch rolling

💖 alpm-source-repo(7) — the group chat guide to source repos 💖

okay so bestie, picture this: you've got a repo — like, an actual directory — and its whole entire job is holding the sources you need to build one (or more!!) Arch Linux Package Management (ALPM) based packages. that's it. that's the vibe. it's giving ✨source material✨.

🌸 DESCRIPTION 🌸

so ALPM based packages (go peek at alpm-package if you haven't, iykyk) don't just appear, right? they get created from package sources using package build software, like makepkg. yeah. that one. 🫶

the Contents section below has the full rundown of which files are required and which are just the optional little extras you'll lowkey wanna have. and if you're doing Arch Linux specific stuff, go look at devtools and pkgctl — those are your girls.

🎀 Contents 🎀

so package sources are represented by a single PKGBUILD per alpm-source-repo. one. singular. iconic behavior honestly. that PKGBUILD may define stuff and/or require additional files — think an alpm-install-scriptlet, or literally arbitrary custom local source files for the package build process, or files for tooling (configuration files, that kinda thing 👀).

and the PKGBUILD script may be accompanied by a SRCINFO file, which is a parseable data format that exposes the relevant metadata defined by the PKGBUILD. slay.

⭐ Required files ⭐

  • PKGBUILD: The package build script.

🦋 Optional files 🦋

  • .SRCINFO: The data representation of the package build script metadata (see SRCINFO).
  • .nvchecker.toml: A minimal configuration file for nvchecker (supported by pkgctl) to allow detection of new upstream versions. new version alert!! 🔔
  • LICENSES/: A directory containing license files used by reuse (see RFC 0040[1] and RFC 0052[2]).
  • REUSE.toml: A configuration file for reuse which covers the license information of all files in the alpm-source-repo (see RFC 0040[1] and RFC 0052[2]).
  • alpm-install-scriptlet: An installation scriptlet that is added to a resulting alpm-package (needs to be specified in the PKGBUILD). ⚠️ yes, it needs to be in the PKGBUILD, don't forget, i'm serious.
  • keys/pgp/: A directory containing ASCII-armored[3] OpenPGP certificates[4] that represent verifiers for OpenPGP signatures[5] created by upstreams for their release artifacts.

apart from all those specific files up there, an alpm-source-repo may contain a list of arbitrary, custom source files that get used with the PKGBUILD when you build package files with package build software. the common ones? patches, systemd.service, systemd.socket, sysusers.d, tmpfiles.d, or other configuration files. love that for us 💅

🌈 Version control 🌈

okay so real talk: it is advisable to keep the contents of an alpm-source-repo in a version control system such as git. why? because doing that lets you establish the relationship between a PKGBUILD and its resulting list of alpm-package files — by associating a (preferably signed) git commit hash with the package. and that? that's important for reproducible builds[6]. no cap. 🔥

upstream sources and build artifacts (think build logs, or package files) should not be included in the git repository. nope. not them. you can ignore them using a gitignore file. alternatively, makepkg.conf can be used to instruct the makepkg package build tool to store artifacts elsewhere. either way, keep that repo clean bestie 🧹✨

👑 Best practices 👑

technically a basic setup only requires a PKGBUILD file. technically. but like… further components are considered best practice and honestly they eat:

  • .SRCINFO: creating this file (see SRCINFO for the description of the format) and keeping it in sync with the PKGBUILD file allows consumers of the alpm-source-repo to extract metadata of the PKGBUILD without requiring bash. no bash required, we love a low-effort queen.
  • .nvchecker.toml: using nvchecker (e.g. through pkgctl) enables users to check for new releases of an upstream project. 🔍
  • LICENSES/ and REUSE.toml: a reuse setup ensures that licensing is clearly defined for all files in the alpm-source-repo, which enables others to use it and adapt it. sharing is caring fr fr.
  • keys/pgp/: if the PKGBUILD defines an alpm-package-source with OpenPGP signature verification[7], storing current versions of relevant ASCII-armored[3] OpenPGP certificates[4] allows users of the alpm-source-repo to authenticate the upstream artifacts using OpenPGP signatures[5]. secure AND cute 🎀

✨ EXAMPLES ✨

first up, the baby version. a basic alpm-source-repo:

.
└── PKGBUILD

and now the glow-up 💖 — a more complete alpm-source-repo with best practices applied for a package named example:

.
├── .SRCINFO
├── .nvchecker.toml
├── LICENSES
│   └── 0BSD.txt
├── PKGBUILD
├── REUSE.toml
├── example.install
└── keys
    └── pgp
        └── F1D2D2F924E986AC86FDF7B36C94BCDF32BEEC15.asc

look at that tree. immaculate. 🌳

🦋 SEE ALSO 🦋

bash(1), git(1), nvchecker(1), pkgctl(1), reuse(1), PKGBUILD(5), SRCINFO(5), alpm-install-scriptlet(5), gitignore(5), makepkg.conf(5), systemd.service(5), systemd.socket(5), sysusers.d(5), tmpfiles.d(5), alpm-package(7), alpm-package-source(7), devtools(7), makepkg(8)

💜 NOTES 💜

  1. RFC 0040

https://rfc.archlinux.page/0040-license-package-sources/

  1. RFC 0052

https://rfc.archlinux.page/0052-reuse/

  1. ASCII armored

https://openpgp.dev/book/armor.html

  1. OpenPGP certificates

https://openpgp.dev/book/certificates.html

  1. OpenPGP signatures

https://openpgp.dev/book/signatures.html

  1. reproducible builds

https://reproducible-builds.org/

  1. OpenPGP signature verification

https://openpgp.dev/book/verification.html

and that's the whole page bestie!! 🌈✨ this little gem lives in the Miscellaneous Information Manual (section 7, she's fancy 💅), and this version is dated 2025-11-21 — so if you're reading this way past that, go check for a glow-up, mwah 🫶💖 🎀

📦 where this page comes from