dsc(5)

📦
version 1.23.11 · 19 versions
, in arch rolling

💅 dsc(5) — the Debian source package control file, explained by your favorite Unix bestie ✨

So like… this is the manual page for dsc(5), and it lives in the dpkg suite, and honestly? It's giving ✨*backstage pass to every Debian source package*✨. Buckle up, we're going in 🫶

🌸 NAME 🌸

dsc — the Debian source package control file format. That's it, that's the vibe. 🎀

🦋 SYNOPSIS 🦋

filename.dsc

Literally the filename. Iconic, low-effort, we respect it. 💅

✨ DESCRIPTION ✨

Okay so every Debian source package comes with a .dsc control file, and that file is stuffed with a bunch of fields, all in deb822(5) format. Think of it as the source package's little ID card 🪪

Each field starts with a tag — things like Source or Binary — and ngl, those tags are case insensitive. Then there's a colon, then the body of the field (and that body is case sensitive unless the page says otherwise). Fields are delimited only by field tags, no cap. So basically: field text can be multiple lines long, but the installation tools will generally join those lines when they process the body of the field — except for the multiline fields Package-List, Files, Checksums-Sha1 and Checksums-Sha256 (see below, bestie, I got you 🫶).

Also the control data might be wrapped up in an OpenPGP ASCII Armored signature, as specified in RFC9580. Cute little armor, we love a protective layer 🛡️

🎀 FIELDS 🎀

The main character fields 👑

  • Format: format-version (required) — this field declares the format version of the source package. Programs acting on a source package use this value to interpret the list of files inside it and figure out how to unpack it. The syntax of the value is a numeric major revision ("0-9"), a period ("."), a numeric minor revision ("0-9"), and then an optional subtype after whitespace (" \t") — and if that subtype is specified, it's a lowercase alphanumeric ("a-z0-9") word in parentheses ("()"). The subtype is optional in the syntax but may be mandatory for particular source format revisions, so like… vibe check your format 👀

The source formats currently supported by dpkg are 1.0, 2.0, 3.0 (native), 3.0 (quilt), 3.0 (git), 3.0 (bzr) and 3.0 (custom). Description of all of those lives in dpkg-source(1). 💖

  • Source: source-name (required) — this value determines the package name, and most installation tools use it to generate file names. It's the name-name, yk? 🏷️
  • Binary: binary-package-list — this folded field lists the binary packages this source package can produce, separated by commas. But heads up: it's now been superseded by the Package-List field, which gives enough info about which binary packages are produced on which architecture, build-profile, and other involved restrictions. So Binary is kinda the older sibling still living in the group chat 🙈
  • Architecture: arch-list (recommended) — this list specifies on which type of machine the package runs. The value should be a list of architecture names and/or wildcards, separated by spaces.

Common architecture names and architecture wildcards are amd64, armel, i386, linux-any, any-amd64, etc. Note that the all value is meant for packages that are architecture independent, and any is for packages that are architecture dependent. The list may include (or consist solely of) the special value all. When the list contains the architecture wildcard any, the only other value allowed in the list is all — that's the rule, periodt 💅

The field value is generally generated from Architecture fields from in the debian/control in the source package.

  • 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. 😭 So like… be careful, fr fr.
  • Origin: name — the name of the distribution this package is originating from. Where it's from, its lore 🌍
  • Maintainer: fullname-email (recommended) — should be in the format “Joe Bloggs <jbloggs@foo.com>”, 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). Main character energy but make it a package 🫶
  • Uploaders: fullname-email-list — lists all the names and email addresses of co-maintainers of the package, in the same format as the Maintainer field. Multiple co-maintainers should be separated by a comma. The format is described in deb-email(7). The whole friend group, basically 🎀
  • Description short-description<br> long-description — the format for the source package description is a short brief summary on the first line (after the Description field). The following lines should be used as a longer, more detailed description. Each line of the long description must be preceded by a space, and blank lines in the long description must contain a single ‘`.`` following the preceding space. Tiny formatting rules, big consequences, slay 💅
  • Homepage: url — the upstream project home page url. Link in bio energy 🔗
  • Standards-Version: version-string (recommended) — documents the most recent version of the distribution policy standards this package complies with. It's the "yes I read the syllabus" field 📚
  • Vcs-Browser: url — the url of a web interface to browse the Version Control System repository. Web UI for the repo, we love a browse 🦋
  • Vcs-Arch: url<br> Vcs-Bzr: url<br> Vcs-Cvs: url<br> Vcs-Darcs: url<br> Vcs-Git: url<br> Vcs-Hg: url<br> Vcs-Mtn: url<br> Vcs-Svn: url — these fields declare the url of the Version Control System repository used to maintain this package. See deb-src-control(5) for more details. A whole little VCS family reunion 🌈
  • Testsuite: name-list — this field declares that the source package contains the specified test suites. The value is a comma-separated list of test suites. If the autopkgtest value is present, a debian/tests/control is expected to be present; if the file is present but not the value, then dpkg-source will automatically add it, preserving previous values. ✨ Testing era ✨
  • Testsuite-Triggers: package-list — this field declares the comma-separated union of all test dependencies (Depends fields in debian/tests/control file), with all restrictions removed, and OR dependencies flattened (that is, converted to separate AND relationships), except for binaries generated by this source package and its meta-dependency equivalent @.

Rationale: this field is needed because otherwise, to be able to get the test dependencies, each source package would need to be unpacked. Unpacking is expensive, your girl is efficient 💅

  • Build-Depends: package-list<br> Build-Depends-Arch: package-list<br> Build-Depends-Indep: package-list<br> Build-Conflicts: package-list<br> Build-Conflicts-Arch: package-list<br> Build-Conflicts-Indep: package-list — these fields declare relationships between the source package and packages used to build it. They are discussed in the deb-src-control(5) manual page. Build squad assemble 🔥

Package-List — the multiline glow-up ✨

The Package-List multiline field contains a list of binary packages generated by this source package. Its shape:

package package-type section priority key-value-list
  • The package is the binary package name. 🏷️
  • The package-type is the binary package type, usually deb, another common value is udeb.
  • The section and priority match the binary package fields of the same name, or if omitted default to unknown and optional respectively (since dpkg 1.22.13).
  • The key-value-list is a space separated key=value list, and the currently known optional keys are:
    • arch — the architecture restriction from the binary package Architecture field, with spaces converted to ‘,’.
    • profile — the normalized build-profile restriction formula from the binary package Build-Profile field, with ANDs (whitespace inside enclosed angle brackets) converted to ‘,’, and ORs (whitespace between enclosing angle brackets) to ‘+’. All angle brackets get removed during normalization.

Deprecated since dpkg 1.23.0, superseded by profile:v1. It's giving legacy 💀

  • profile:v1 — the normalized build-profile restriction formula from the binary package Build-Profile field, with ANDs (whitespace inside enclosed angle brackets) converted to ‘&’, and ORs (whitespace between enclosing angle brackets) to ‘|’. All angle brackets get removed during normalization.

Supported since dpkg 1.23.0. The fresh new version, we stan 🫶

  • protected — if the binary package is protected, this key will contain the value of the Protected field, that is a yes value.

Supported since dpkg 1.20.1.

  • essential — if the binary package is essential, this key will contain the value of the Essential field, that is a yes value.

Files, Checksums-Sha1, Checksums-Sha256 — the checksum trio 🧚

  • Files: (required, weak)
  • Checksums-Sha1: (required, weak)
  • Checksums-Sha256: (required, strong)

Their line shape is:

checksum size filename

These multiline fields contain a list of files with a checksum and size for each one. They all have the same syntax and differ only in the checksum algorithm used: MD5 for Files, 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 of the field is expressed as continuation lines, one line per file. Each line consists of the checksum, a space, the file size, a space, and the file name. 🎀

These fields list all files that make up the source package. The list of files in these fields must match the list of files in the other related fields. No skipping, no freeloading files, bestie.

Note: the MD5 and SHA-1 checksums are considered weak, and should never be assumed to be sufficient for secure verification. Like, do not trust them with your life, fr fr 😭

💀 BUGS 💀

The Format field conflates the format for the .dsc file itself and the format of the extracted source package. One field, two jobs, zero work-life balance 🙈

🔥 SEE ALSO 🔥

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

Go read those too, iykyk 💜

Okay that's the whole page, bestie — brought to you by version 1.23.11-dirty, dated 2026-09-09 🎀✨ Thanks for reading, you ate that, no cap 💅

📦 where this page comes from