deb-buildinfo(5)

✨ deb-buildinfo(5) ✨

okay so bestie, let me tell you about deb-buildinfo(5) — the Debian build information file format, part of the dpkg suite, and honestly it's giving organized queen energy 💅

🌸 SYNOPSIS 🌸

filename.buildinfo

🦋 DESCRIPTION 🦋

So every Debian source package build can record its whole build info in a .buildinfo control file, and that file contains a bunch of fields in deb822(5) format. Think of it like the build's little diary 📓✨

Each field begins with a tag, like Source or Binary (case insensitive, bestie), followed by a colon, and then the body of the field (which is case sensitive unless stated otherwise). Fields are delimited only by field tags. In other words, field text can be multiple lines long, but the installation tools will generally join lines when processing the body of the field — except for the multiline fields Binary-Only-Changes, Installed-Build-Depends, Environment, Checksums-Md5, Checksums-Sha1 and Checksums-Sha256 (see below, iykyk).

The control data might be enclosed in an OpenPGP ASCII Armored signature, as specified in RFC9580. Fancy, right? 🔐

The name of the .buildinfo file depends on the type of build and will be as specific as necessary but not more. The name will be:

• source-name_binary-version_arch.buildinfo — for a build that includes any
• source-name_binary-version_all.buildinfo — otherwise for a build that includes all
• source-name_source-version_source.buildinfo — otherwise for a build that includes source

---

🎀 FIELDS 🎀

Format: format-version (required) 🌟

The value of this field declares the format version of the file. The syntax of the field value is a version number with a major and minor component. Backward incompatible changes to the format will bump the major version, and backward compatible changes (like field additions) will bump the minor version. The current format version is 1.0. Slay, versioning 💖

Source: source-name [(source-version)] (required) 🌈

The name of the source package. If the source version differs from the binary version, then the source-name will be followed by a source-version in parenthesis. This can happen when the build is for a binary-only non-maintainer upload. No cap.

Binary: binary-package-list (required in context) 🧚

This folded field is a space-separated list of binary packages built. If the build is source-only, then the field is omitted (since dpkg 1.20.0). Periodt.

Architecture: arch-list (required) 🏗️

The architecture list specifies on which type of machine this package runs. The value should be a list of architecture names separated by spaces.

Common architectures are amd64, armel, i386, etc. Note that the special all value is meant for packages that are architecture independent (like shell and Perl scripts or documentation). If the source for the package is also being built, the special entry source is also present.

⚠️ Note: Architecture wildcards are not allowed in this context. Don't even try it, bestie.

Version: version-string (required) 🔢

Typically, this is the original package's version number in whatever form the program's author uses. It may also include a Debian revision number (for non-native packages). The exact format and sorting algorithm are described in deb-version(7).

⚠️ Note: On some vendors, dpkg has been made to permit native sources with non-native versions, making this incoherent and adding to the confusion of the concept, where in addition this tends to be a trap for accidental mistakes. Lowkey a mess, but that's the tea 💀

Binary-Only-Changes: changelog-entry 📝

This multiline field contains the concatenated text of the changelog entry for a binary-only non-maintainer upload (binNMU) if that is the case. To make this a valid multiline field, empty lines are replaced with a single full stop (‘.’) and all lines are indented by one space character. The exact content depends on the changelog format.

Checksums-Md5: (required, weak) / Checksums-Sha1: (required, weak) / Checksums-Sha256: (required, strong) — checksum size filename 🔐

These multiline fields contain a list of files with a checksum and size for each one. These fields have the same syntax and differ only in the checksum algorithm used: MD5 for Checksums-Md5, SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256.

⚠️ Note: The MD5 and SHA-1 checksums are considered weak, and should never be assumed to be sufficient for secure verification. Ngl, don't trust them for security stuff 💅

The first line of the field value (the part on the same line as the field name followed by a colon) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of space-separated entries describing the file: the checksum, the file size, and the file name.

These fields list all files that make up the build. Iconic.

Build-Origin: name 🌍

The name of the distribution this package is originating from.

Build-Architecture: arch (required) 💻

The Debian architecture for the installation the packages is being built in. Common architectures are amd64, armel, i386, etc.

Build-Date: build-date 📅

The date the package was built. It must be in the same format as the date in a deb-changelog(5) entry.

Build-Kernel-Version: build-kernel-version 🧠

The release and version (in an unspecified format) of the kernel running on the build system. This field is only going to be present if the builder has explicitly requested it, to avoid leaking possibly sensitive information. Privacy queen behavior 🔒

Build-Path: build-path 📂

The absolute build path, which corresponds to the unpacked source tree. This field is only going to be present if the vendor has allowed it via some pattern match to avoid leaking possibly sensitive information.

On Debian and derivatives, only build paths starting with /build/ will emit this field.

Build-Tainted-By: taint-reason-list 🚩

This folded field contains a space-separated list of non-exhaustive reason tags (formed by alphanumeric and dash characters) which identify why the current build has been tainted.

Supported since dpkg 1.19.5.

On Debian and derivatives the following reason tags can be emitted:

• usr-local-has-configs — The system has configuration files under /usr/local/etc.
• usr-local-has-includes — The system has header files under /usr/local/include.
• usr-local-has-programs — The system has programs under /usr/local/bin or /usr/local/sbin.
• usr-local-has-libraries — The system has libraries, either static or shared under /usr/local/lib.
• can-execute-cross-built-programs — The system can execute cross built programs, either directly or via some emulation layer. (Since dpkg 1.21.10.)

Installed-Build-Depends: (required) — package-list 📦

The list of installed and configured packages that might affect the package build process.

The list consists of each package name, optionally arch-qualified for foreign architectures, with an exact version restriction, separated by commas.

The list includes all essential packages, packages listed in Build-Depends, Build-Depends-Arch, Build-Depends-Indep source control fields, any vendor specific builtin dependencies, and all their recursive dependencies. On Debian and derivatives the dependency builtin is build-essential.

For dependencies coming from the source control fields, all dependency alternatives and all providers of virtual packages depended on will be included. Thorough much? Obsessed 💖

Environment: variable-list 🌱

The list of environment variables that are known to affect the package build process, with each environment variable followed by an equal sign (‘=’) and the variable's quoted value, using double quotes (‘"’), and backslashes escaped (‘\\’).

---

🌟 SEE ALSO 🌟

deb822(5), deb-changes(5), deb-version(7), dpkg-genbuildinfo(1).

---

and that's the whole vibe bestie ✨ this page is from dpkg suite version 1.23.11-dirty, dated 2026-09-09 — go off and read those buildinfo files like the main character you are 👑💖