BUILDINFOV2(5)

πŸ“¦ version 0.6.0, in arch rolling

πŸ’– BUILDINFO(5) β€” the whole vibe of BUILDINFO files, version 2 πŸ’–

okay so bestie, this is the manual page for BUILDINFO in the File Formats Manual, section (5). it's a lot of words about a little text file and ngl it's actually kind of iconic. let's get into it 🌸


✨ NAME ✨

BUILDINFO β€” Information on package build environments for ALPM based packages (version 2). periodt. that's the whole name. πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

The BUILDINFO format is a textual format that describes a package's build environment. these files live at the root of ALPM packages, they're named .BUILDINFO, and they're usually used to reproduce the environment in which a package has been built. for further information, go look at Arch Linux's reproducible builds effort (note 1 at the bottom, iykyk ✨).

The BUILDINFO format exists in multiple versions. the info in this doc is for version 2, which is the current version and was introduced with the release of pacman 6.0.0 on 2021-05-20. a whole era πŸ‘‘

πŸŽ€ Changes since the last version πŸŽ€

The new keywords buildtool and buildtoolver have been added to track the package name, version and architecture of the tool used to setup the build environment for a package. glow-up fr fr πŸ’–

🌈 General Format 🌈

A BUILDINFO file consists of a series of lines, each one providing information on an aspect of the build environment of a package, or on the file format itself. leading whitespace is always ignored. (not me adding a bunch of spaces at the start of every line and it just working 😌)

Unless noted otherwise, the information contained in a BUILDINFO file is considered to be covered by the set of the 95 printable ASCII characters.

🫢 Keywords 🫢

Each line encodes information that represents one keyword assignment. all keyword assignments consist of a key from the following list, immediately followed by a whitespace, an = sign, another whitespace, and a value. so like key + whitespace + = + whitespace + value, bestie. exact order, no skipping πŸ’…

By default, exactly one keyword assignment must be present per keyword in a BUILDINFO. as the exception to this rule, the keywords buildenv, options and installed may be provided zero or more times. those three are the main characters with main character energy πŸ’€

Here's the full cast, one by one:

  • format β€” the BUILDINFO file format version. should be the first keyword in the BUILDINFO file (put it first, it's the opening act 🎬). the value must be a plain positive integer, and it must be 2 for version 2.
  • pkgname β€” the name of the package. the value is an alpm-package-name (e.g. example).
  • pkgbase β€” the alpm-package-base of the package. the value is an alpm-package-base (e.g. example).
  • pkgver β€” the full version of the package. note that this is not to be confused with alpm-pkgver, which only represents a subset of this keyword! (they are NOT the same, don't do that πŸ™ˆ) the value is an alpm-package-version, either in full form or in full with epoch form (e.g. 1.0.0-1 or 1:1.0.0-1, respectively).
  • pkgarch β€” the architecture of the package (see alpm-architecture for further information). the value must be covered by the set of alphanumeric characters and _ (e.g. x86_64 or any).
  • pkgbuild_sha256sum β€” the hex representation of the SHA-256 checksum of the PKGBUILD used to build the package. the value must be covered by the set of hexadecimal characters and must be 64 characters long (e.g. 946d8362de3cebe3c86765cb36671a1dfd70993ac73e12892ac7ac5e6ff7ef95).
  • packager β€” the User ID of the entity that built the package. the value is meant to be used for identity lookups and represents an OpenPGP User ID (see note 2). as such, the value is a UTF-8-encoded string, conventionally composed of a name and an e-mail address, which aligns with the format described in RFC 28223.
  • builddate β€” the date at which the build of the package started. the value must be numeric and represent the seconds since the Epoch, aka. Unix time (e.g. 1729181726).
  • builddir β€” the absolute directory path in which the package has been built by the build tool (e.g. makepkg). the value is a UTF-8-encoded string and must represent a valid absolute directory (e.g. /builddir).
  • startdir β€” the directory from which makepkg was executed. the value is a UTF-8-encoded string and must represent a valid absolute directory (e.g. /startdir).
  • buildtool β€” the package name of the tool used to set up the build environment. this helps Arch Linux's Reproducible Builds effort reproduce the environment in which a package has been built. the value must be a valid package name as described in pkgname.
  • buildtoolver β€” the full version of the buildtool used to set up the build environment. the value may take one of two forms:
    • An alpm-package-version in full or in full with epoch form (e.g. 1.0.0-1 or 1:1.0.0-1, respectively), directly followed by a - sign, directly followed by an alpm-architecture (e.g. 1.0.0-1-any or 1:1.0.0-1-any, respectively). this format is commonly used by Arch Linux's build tools. πŸ› οΈ
    • An alpm-package-version in minimal or in minimal with epoch form (e.g. 1.0.0 or 1:1.0.0, respectively). this format is commonly used by makepkg.
  • buildenv β€” a build environment used by the package build tool (i.e. makepkg, defined in BUILDENV of makepkg.conf) when building the package. this keyword may be assigned zero or more times. the value must be a unique word, optionally prefixed by a single !, which indicates the negation of the environment (e.g. color or !color).
  • options β€” an option used by the package build tool (i.e. makepkg, defined in OPTIONS of makepkg.conf) when building the package. this keyword may be assigned zero or more times. the value must be a unique word, optionally prefixed by a single !, which indicates the negation of the option (e.g. debug or !debug).
  • installed β€” the information about an installed package during build time of the package. this keyword may be assigned zero or more times. the value represents a composite string, composed of an alpm-package-name, directly followed by a - sign, directly followed by an alpm-package-version (in full or in full in epoch form), directly followed by a - sign, followed by an alpm-architecture (e.g. example-1:1.0.0-1-x86_64). stack it like a little sandwich πŸ₯ͺ

πŸ”₯ EXAMPLES πŸ”₯

here's a full one, bestie β€” look at her go πŸ˜­πŸ’–

format = 2
pkgname = example
pkgbase = example
pkgver = 1:1.0.0-1
pkgarch = any
pkgbuild_sha256sum = b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
packager = John Doe <john@example.org>
builddate = 1729181726
builddir = /build
startdir = /startdir/
buildtool = devtools
buildtoolver = 1:1.2.1-1-any
buildenv = !color
buildenv = check
options = !strip
options = staticlibs
installed = other-package-1:0.5.0-3-any
installed = package2-2.1.0-6-x86_64

see how buildenv, options and installed show up more than once? that's the zero-or-more exception doing its thing ✨


🧚 SEE ALSO 🧚

go read these next, they're all in the group chat too:


🌟 NOTES 🌟

  1. Arch Linux's Reproducible Builds effort https://wiki.archlinux.org/title/Reproducible_builds
  2. OpenPGP User ID https://openpgp.dev/book/certificates.html#user-ids
  3. RFC 2822 https://www.rfc-editor.org/rfc/rfc2822

lowkey a warning but mostly a vibe check: pkgver is not alpm-pkgver, and pkgbuild_sha256sum has to be exactly 64 hex characters or it's not slaying. you've been warned πŸ’€

okay that's the whole page!! this came to you straight out of the File Formats Manual, section (5) β€” BUILDINFO(5), version 2, the current one, no cap πŸ’…πŸŽ€βœ¨ bestie you ate that. go build something reproducible πŸ¦‹

πŸ“¦ where this page comes from