deb-changes(5)

📦
version 1.23.11 · 19 versions
, in arch rolling

💅 deb-changes(5) — the dpkg suite's little upload receipt

okay so bestie, welcome to the manual page for deb-changes, which lives in the dpkg suite and is literally the control file format for a Debian upload. strap in 🎀

✨ NAME

deb-changes — the Debian upload changes control file format. that's it, that's the vibe 💖

✨ SYNOPSIS

filename.changes

✨ DESCRIPTION

so every Debian upload is made up of a .changes control file, and that file is full of fields in the deb822(5) format. iconic behavior honestly 🦋

Each field starts with a tag, like Source or Binary (case insensitive, no cap), then a colon, then the body of the field (which is case sensitive unless someone says otherwise). Fields are delimited only by field tags — meaning the text of a field can totally be multiple lines long, but the installation tools will generally join those lines when they process the body. the exceptions are the multiline fields Description, Changes, Files, Checksums-Sha1 and Checksums-Sha256 — those keep their shape, see below 🌸

also the control data might be wrapped in an OpenPGP ASCII Armored signature, as specified in RFC9580. fancy ✨

✨ FIELDS

  • Format: format-version (required) — this field declares the format version of the file. the syntax of the value is a version number with a major and a minor component. backward incompatible changes bump the major version, and backward compatible ones (like adding fields) bump the minor version. the current format version is 1.8.
  • Date: release-date (required) — the date the package was built or last edited. it has to be in the same format as the date in a deb-changelog(5) entry.

the value of this field is usually extracted from the debian/changelog file.

  • 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 gets followed by a source-version in parenthesis. this can happen when the upload is a binary-only non-maintainer upload 👑
  • Binary: binary-package-list (required in context) — this folded field is a space-separated list of binary packages to upload. if the upload is source-only, the whole field is omitted (since dpkg 1.19.3) 🙈
  • Architecture: arch-list — lists the architectures of the files currently being uploaded.

common architectures are amd64, armel, i386, etc. note that the special value all is meant for packages that are architecture independent (think shell and Perl scripts or documentation). if the source for the package is also being uploaded, the special entry source is present too.

Note: Architecture wildcards are not allowed in this context. periodt.
  • 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, which makes this incoherent and adds to the confusion of the concept — and on top of that it tends to be a trap for accidental mistakes 💀
  • Distribution: distributions (required) — lists one or more space-separated distributions where this version should be installed when it's uploaded to the archive.
  • Urgency: urgency (recommended) — the urgency of the upload. the currently known values, in increasing order of urgency, are: low, medium, high, critical and emergency 🔥
  • Maintainer: fullname-email (required) — should be in the format “Joe Bloggs <jbloggs@example.org>”, and is typically the person who created the package, as opposed to the author of the software that was packaged.

the format is described in deb-email(7).

  • Changed-By: fullname-email — should be in the format “Joe Bloggs <jbloggs@example.org>”, and is typically the person who prepared the package changes for this release.

the format is described in deb-email(7).

  • Description: (recommended)
 binary-package-name - binary-package-summary

this multiline field contains a list of binary package names followed by a space, a dash (‘-’) and their possibly truncated short descriptions. if the upload is source-only, the field is omitted (since dpkg 1.19.3) 🫶

  • Closes: bug-number-list — a space-separated list of bug report numbers for bug reports that have been resolved with this upload. the distribution archive software might use this field to automatically close the referred bug numbers in the distribution bug tracking system. slay, automation 💅
  • Binary-Only: yes — this field denotes that the upload is a binary-only non-maintainer build. it originates from the binary-only=yes key/value from the changelog metadata entry.
  • Built-For-Profiles: profile-list — this field specifies a whitespace separated list of build profile names (without exclamation marks) that this upload was built with.
  • Changes: (required)
 changelog-entries

this multiline field contains the concatenated text of all changelog entries that are part of the upload. 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 🌈

  • Files: (required)
 md5sum size section priority filename

this multiline field contains a list of files with an md5sum, size, section and priority for each one.

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 is expressed as continuation lines, one line per file. each line consists of space-separated entries describing the file: the md5sum, the file size, the file section, the file priority, and the file name.

if the section is omitted in the source package template control file, it defaults to unknown (since dpkg 1.22.13).

if the priority is omitted in the source package template control file, it defaults to optional (since dpkg 1.22.13).

this field lists all the files that make up the upload. the list of files in this field must match the list of files in the other related Checksums fields.

Note: the MD5 checksum is considered weak, and should never be assumed to be sufficient for secure verification — but this field cannot be omitted, because it provides metadata not available anywhere else. iykyk 😭
  • 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. they have the same syntax and differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256.

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 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 the files that make up the upload. the list of files in these fields must match the list of files in the Files field and the other related Checksums fields.

Note: the SHA-1 checksum is considered weak, and should never be assumed to be sufficient for secure verification. bestie i'm begging you 🧚

💀 BUGS

  • the Files field is inconsistent with the other Checksums fields.
  • the Changed-By and Maintainer fields have confusing names.
  • the Distribution field contains information about what is commonly referred to as a suite.

not me listing the lore-accurate gripes fr fr 🍓

🌸 SEE ALSO

deb822(5), deb-src-control(5), deb-email(7), deb-version(7).

and that's the whole page bestie, go build something iconic 💜

signing off from the dpkg suite, version 1.23.11-dirty, dated 2026-09-09 — mwah 🎀

📦 where this page comes from