dpkg-source(1)

📦
version 1.23.11 · 19 versions
, in arch rolling

💅 dpkg-source(1) — Debian source package (.dsc) manipulation tool, straight from the dpkg suite 💅

🌸 NAME 🌸

dpkg-source — Debian source package (.dsc) manipulation tool ✨

✨ SYNOPSIS ✨

dpkg-source [option...] command

🦋 DESCRIPTION 🦋

Okay bestie, so dpkg-source packs and unpacks Debian source archives. That’s literally the whole job. 💖

Two rules, no cap: none of these commands let you smoosh multiple options into one, and they do not allow the value for an option to be specified in a separate argument. Keep it together, bestie. 😌

🎀 COMMANDS 🎀

  • -x, --extract filename.dsc [output-directory] — extract a source package (--extract). You must supply one non-option argument: the name of the Debian source control file (.dsc). You can also supply an optional second non-option argument to specify the directory to extract the source package to — and it must not exist. If no output directory is specified, the source package is extracted into a directory named source-version under the current working directory. 📂

dpkg-source will read the names of the other file(s) making up the source package from the control file; they are assumed to be in the same directory as the .dsc.

The files in the extracted package will have their permissions and ownerships set to those which would have been expected if the files and directories had been created — directories and executable files will be 0777 and plain files will be 0666, both modified by the extractors' umask; if the parent directory is setgid then the extracted directories will be too, and all the files and directories will inherit its group ownership. 🔥

If the source package uses a non-standard format (currently this means all formats except 1.0), its name will be stored in debian/source/format so that the following builds of the source package use the same format by default. 🫶

Supported since dpkg 1.17.14.

  • -b, --build directory [format-specific-parameters] — build a source package. The first non-option argument is taken as the name of the directory containing the debianized source tree (i.e. with a debian sub-directory and maybe changes to the original files). Depending on the source package format used to build the package, additional parameters might be accepted. 👑

dpkg-source will build the source package with the first format found in this ordered list: the format indicated with the --format command line option, the format indicated in debian/source/format, then 1.0. The fallback to 1.0 is deprecated and will be removed at some point in the future, so you should always document the desired source format in debian/source/format. See section "SOURCE PACKAGE FORMATS" for an extensive description of the various source package formats. 📚

Support for long option since dpkg 1.17.14.

  • --print-format directory — print the source format that would be used to build the source package if dpkg-source --build directory was called (in the same conditions and with the same parameters). 🖨️✨

Supported since dpkg 1.15.5.

  • --before-build directory — run the corresponding hook of the source package format. This hook is called before any build of the package (dpkg-buildpackage calls it very early even before debian/rules clean). This command is idempotent and can be called multiple times. Not all source formats implement something in this hook, and those that do usually prepare the source tree for the build, for example by ensuring that the Debian patches are applied. 🧚💜

Supported since dpkg 1.15.8.

  • --after-build directory — run the corresponding hook of the source package format. This hook is called after any build of the package (dpkg-buildpackage calls it last). This command is idempotent and can be called multiple times. Not all source formats implement something in this hook, and those that do usually use it to undo what --before-build has done. 🌈

Supported since dpkg 1.15.8.

  • --commit [directory] ... — record changes in the source tree unpacked in directory. 🎀

This command can take supplementary parameters depending on the source format. It will error out for formats where this operation doesn't mean anything. 💀

Supported since dpkg 1.16.1.

  • -?, --help — show the usage message and exit. The format specific build and extract options can be shown by using the --format option. 💅
  • --version — show the version and exit. 👑

✨ OPTIONS ✨

🛠️ Generic build options 🛠️

okay so these are the knobs you turn when you're building a source package, bestie. every flag, every default, every tiny version note — it's all here, no skips.

  • -ccontrol-file — tells dpkg-source which main source control file to read info from. the default is debian/control. if you give a relative pathname, it's interpreted starting at the source tree's top level directory. 💖
  • -lchangelog-file — picks the changelog file to read info from. default is debian/changelog. same relative-path rule: it starts at the source tree's top level directory. 🎀
  • -Fchangelog-format — sets the format of the changelog. see dpkg-parsechangelog(1) for the whole tea on alternative formats. 🦋
  • --format=value — use this format when building the source package. it does override any format given in debian/source/format. supported since dpkg 1.14.17. ✨
  • -Vname=value — set an output substitution variable (that's the -Vname flag with a name=value pair). see deb-substvars(5) for a full discussion of output substitution. 💅
  • -Tsubstvars-file — read substitution variables from substvars-file; the default is to not read any file. you can use this option multiple times to read substitution variables from multiple files. supported since dpkg 1.15.6. 🫶
  • -Dfield=value — override or add an output control file field (the -Dfield flag with field=value). 👑
  • -Ufield — remove an output control file field. bye, field. 💀
  • -Zcompression, --compression=compression — specify the compression to use for created tarballs and diff files. important: this will not cause existing tarballs to be recompressed, it only affects new files. supported values are: gzip, bzip2, lzma and xz. the default is xz for formats 2.0 and newer, and gzip for format 1.0. support for short option since dpkg 1.14.8. support for long option since dpkg 1.15.5. support for xz compression since dpkg 1.15.5. 🌸
  • -zlevel, --compression-level=level — compression level to use. as with -Z it only affects newly created files. supported values are: 1 to 9, best, and fast. the default is 9 for gzip and bzip2, 6 for xz and lzma. support for short option since dpkg 1.14.8. support for long option since dpkg 1.15.5. 🔥
  • -i[regex], --diff-ignore[=regex] — you may specify a perl regular expression to match files you want filtered out of the list of files for the diff. (this list is generated by a find command.) if the source package is being built as a version 3 source package using a VCS, this can be used to ignore uncommitted changes on specific files. using -i.* will ignore all of them. 👀

the -i option by itself enables this setting with a default regex (preserving any modification to the default regex done by a previous use of --extend-diff-ignore) that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. there can only be one active regex, of multiple -i options only the last one will take effect. 🎯

this is very helpful in cutting out extraneous files that get included in the diff, for example if you maintain your source in a revision control system and want to use a checkout to build a source package without including the additional files and directories that it will usually contain (e.g. CVS/, .cvsignore, .svn/). the default regex is already very exhaustive, but if you need to replace it, note that by default it can match any part of a path, so if you want to match the begin of a filename or only full filenames, you will need to provide the necessary anchors (e.g. (^|/), ($|/)) yourself. 🧚

support for long option since dpkg 1.15.6. 💜

  • --extend-diff-ignore=regex — the perl regular expression specified will extend the default value used by --diff-ignore and its current value, if set. it does this by concatenating |regex to the existing value. this option is convenient to use in debian/source/options to exclude some auto-generated files from the automatic patch generation. supported since dpkg 1.15.6. 🌈
  • -I[file-pattern], --tar-ignore[=file-pattern] — if this option is specified, the pattern will be passed to tar(1)'s --exclude option when it is called to generate a .orig.tar or .tar file. for example, -ICVS will make tar skip over CVS directories when generating a .tar.gz file. the option may be repeated multiple times to list multiple patterns to exclude. 🍓

-I by itself adds default --exclude options that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. support for long option since dpkg 1.15.6. 🌟

Note, bestie: while they have similar purposes, -i and -I have very different syntax and semantics. -i can only be specified once and takes a perl compatible regular expression which is matched against the full relative path of each file. -I can be specified multiple times and takes a filename pattern with shell wildcards. the pattern is applied to the full relative path but also to each part of the path individually. the exact semantic of tar's --exclude option is somewhat complicated, see https://www.gnu.org/software/tar/manual/tar.html#wildcards for a full documentation. 🫡

the default regex and patterns for both options can be seen in the output of the --help command. 📖

🧳 Generic extract options 🧳

extract era — these control what happens when dpkg-source unpacks a source package.

  • --no-copy — do not copy original tarballs near the extracted source package. supported since dpkg 1.14.17. 💖
  • --no-check — do not check signatures and checksums before unpacking. supported since dpkg 1.14.17. 🎀
  • --no-overwrite-dir — do not overwrite the extraction directory if it already exists. supported since dpkg 1.18.8. 🦋
  • --no-vendor-certs — do not use the vendor specific certificate keyrings. supported since dpkg 1.23.0. ✨
  • --signer-certs=keyring — use this keyring containing signer certificates during signature verification of source packages. the option may be repeated multiple times to add multiple keyrings. supported since dpkg 1.23.0. 💅
  • --require-valid-signature — refuse to unpack the source package if it doesn't contain an OpenPGP signature that can be verified either with the user supplied --signer-certs keyrings, or one of the vendor-specific keyrings, including any parent vendor keyrings if relevant. supported since dpkg 1.15.0. 🔐
  • --require-strong-checksums — refuse to unpack the source package if it does not contain any strong checksums. currently the only known checksum considered strong is SHA-256. supported since dpkg 1.18.7. 🔥
  • --ignore-bad-version — turns the bad source package version check into a non-fatal warning. this option should only be necessary when extracting ancient source packages with broken versions, just for backwards compatibility. supported since dpkg 1.17.7. 🕰️

🎛️ Generic general options 🎛️

  • --threads-max=threads — sets the maximum number of threads allowed for compressors that support multi-threaded operations. supported since dpkg 1.21.14. ⚡
  • -q — sets quiet mode to suppress warnings. shhh. 🤫

🌈 SOURCE PACKAGE FORMATS 🌈

if you don't know what source format to use, you should probably pick either 3.0 (quilt) or 3.0 (native). see https://wiki.debian.org/Projects/DebSrc3.0 for information on the deployment of those formats within Debian. 💖

🕰️ Format: 1.0 🕰️

a source package in this format consists either of a .orig.tar.gz associated to a .diff.gz or a single .tar.gz (in that case the package is said to be native). optionally the original tarball might be accompanied by a detached upstream signature .orig.tar.gz.asc. 🎀

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. ⚠️

support for upstream signatures during extraction since dpkg 1.18.5. support for upstream signatures during building since dpkg 1.19.0. ✨

📦 Extracting 📦

extracting a native package is a simple extraction of the single tarball in the target directory. extracting a non-native package is done by first unpacking the .orig.tar.gz and then applying the patch contained in the .diff.gz file. the timestamp of all patched files is reset to the extraction time of the source package (this avoids timestamp skews leading to problems when autogenerated files are patched). the diff can create new files (the whole debian directory is created that way) but cannot remove files (empty files will be left over) and cannot create or change symlinks. 🫶

🏗️ Building 🏗️

building a native package is just creating a single tarball with the source directory. building a non-native package involves extracting the original tarball in a separate “.orig” directory and regenerating the .diff.gz by comparing the source package directory with the .orig directory. 💅

⚙️ Build options (with --build): ⚙️

if a second non-option argument is supplied it should be the name of the original source directory or tarfile or the empty string if the package is a Debian-specific one and so has no debianization diffs. if no second argument is supplied then dpkg-source will look for the original source tarfile package_upstream-version.orig.tar.gz or the original source directory directory.orig depending on the -sX arguments. 🧚

-sa, -sp, -sk, -su and -sr will not overwrite existing tarfiles or directories. if this is desired then -sA, -sP, -sK, -sU and -sR should be used instead. 🔥

  • -sk — specifies to expect the original source as a tarfile, by default package_upstream-version.orig.tar.extension. it will leave this original source in place as a tarfile, or copy it to the current directory if it isn't already there. the tarball will be unpacked into directory.orig for the generation of the diff. 💖
  • -sp — like -sk but will remove the directory again afterwards. 🎀
  • -su — specifies that the original source is expected as a directory, by default package-upstream-version.orig and dpkg-source will create a new original source archive from it. 🦋
  • -sr — like -su but will remove that directory after it has been used. ✨
  • -ss — specifies that the original source is available both as a directory and as a tarfile. dpkg-source will use the directory to create the diff, but the tarfile to create the .dsc. this option must be used with care — if the directory and tarfile do not match a bad source archive will be generated. 😭
  • -sn — bestie, this one says don't even look for an original source, and don't generate a diff either. If you pass a second argument it must be the empty string. It's for those Debian-specific packages that straight-up don't have a separate upstream source, so there's literally nothing to debianize and no diff to make. 🫶
  • -sa or -sA — this one's like "go look for the original source archive, okay?" and it'll accept a tarfile or a directory as the second argument (or the empty string, which is exactly the same as using -sn). Here's the tea:
    • if a tarfile turns up, it unpacks it to create the diff and removes it afterwards — same as -sp
    • if a directory turns up, it packs it to create the original source and removes it afterwards — same as -sr
    • if neither turns up, it just assumes the package has no debianization diffs and is only a straightforward source archive — same as -sn
    • if both turn up, then dpkg-source will ignore the directory and overwrite it if -sA was given (same as -sP), or it will raise an error if -sa was given 😭

-sa is the default, so if you didn't pick anything, congrats, you picked this one. ✨

  • --abort-on-upstream-changes — the process fails if the generated diff contains changes to files outside of the debian sub-directory. Like, stay in your lane, upstream. 🚧 This option is not allowed in debian/source/options, but you can use it in debian/source/local-options.

Supported since dpkg 1.15.8.

Extract options (with --extract) 💅

Heads up before we start: in all cases, any existing original source tree will be removed. Gone. Bye. 🫡

  • -sp — used when extracting, the original source (if there is any) will be left as a tarfile. If it's not already chilling in the current directory, or if there's an existing but different file sitting there, it gets copied there. (This is the default, so it's giving main character energy by default.)
  • -su — unpacks the original source tree.
  • -sn — ensures that the original source is neither copied to the current directory nor unpacked. But the plot twist? Any original source tree that was in the current directory is still removed. No cap. 💀
All the -sX options are mutually exclusive. If you specify more than one, only the last one will be used. Pick a lane, bestie. 🎀
  • --skip-debianization — skips application of the debian diff on top of the upstream sources.

Supported since dpkg 1.15.1.

Format: 2.0 🌸

Also known as wig&pen, which is honestly such a cute name. This format is not recommended for wide-spread usage — the format “3.0 (quilt)” replaces it. Wig&pen was the first specification of a new-generation source package format, so it's like the ancestor, the origin story, the grandmother of them all. 👑

The behavior of this format is the same as the “3.0 (quilt)” format, except that it doesn't use an explicit list of patches. Instead: all files in debian/patches/ matching the perl regular expression [\w-]+ must be valid patches, and they are applied at extraction time. That's it, that's the rule. 🦋

When building a new source package, any change to the upstream source is stored in a patch named zz_debian-diff-auto.

Support for extraction since dpkg 1.13.9. Support for building since dpkg 1.14.8.

Format: 3.0 (native) ⭐

This format is an extension of the native package format as defined in the 1.0 format. It supports all compression methods and will, by default, ignore any VCS specific files and directories as well as many temporary files (see the default value associated to the -I option in the --help output).

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, it's giving "undefined vibes" in a way that will bite you. 🙈

Supported since dpkg 1.14.17.

Format: 3.0 (quilt) 🧚

A source package in this format contains at least an original tarball (.orig.tar.ext where ext can be gz, bz2, lzma and xz) and a debian tarball (.debian.tar.ext). It can also contain additional original tarballs (.orig-addon.tar.ext). The addon part can only contain alphanumeric (a-zA-Z0-9) characters and hyphens (-). And optionally, each original tarball can be accompanied by a detached upstream signature (.orig.tar.ext.asc and .orig-addon.tar.ext.asc). So many extensions, so little time. 💅

Supported since dpkg 1.14.17. Support for upstream signatures during extraction since dpkg 1.17.20. Support for upstream signatures during building since dpkg 1.18.5.

Extracting 🎀

The main original tarball is extracted first, then all additional original tarballs are extracted in subdirectories named after the addon part of their filename (any pre-existing directory is replaced — no mercy). The debian tarball is extracted on top of the source directory after prior removal of any pre-existing debian directory. Note that the debian tarball must contain a debian sub-directory but it can also contain binary files outside of that directory (see the --include-binaries option). 👀

All patches listed in debian/patches/vendor.series or debian/patches/series are then applied, where vendor will be the lowercase name of the current vendor, or debian if there is no vendor defined. If the former file is used and the latter one doesn't exist (or is a symlink), then the latter is replaced with a symlink to the former. This is meant to simplify usage of quilt to manage the set of patches. 🔥

Vendor-specific series files are intended to make it possible to serialize multiple development branches based on the vendor, in a declarative way, in preference to open-coding this handling in debian/rules. This is particularly useful when the source would need to be patched conditionally because the affected files do not have built-in conditional occlusion support. Note however that while dpkg-source parses correctly series files with explicit options used for patch application (stored on each line after the patch filename and one or more spaces), it does ignore those options and always expects patches that can be applied with the -p1 option of patch. It will thus emit a warning when it encounters such options, and the build is likely to fail. 😭

Note that lintian(1) will emit unconditional warnings when using vendor series due to a controversial Debian specific ruling, which should not affect any external usage; to silence these, the dpkg lintian profile can be used by passing «--profile dpkg» to lintian(1). So it's not you, it's the ruling. 🫶

The timestamp of all patched files is reset to the extraction time of the source package (this avoids timestamp skews leading to problems when autogenerated files are patched). Time is literally a construct here. ⏰

Contrary to quilt's default behavior, patches are expected to apply without any fuzz. When that's not the case, you should refresh such patches with quilt, or dpkg-source will error out while trying to apply them. No fuzzy vibes allowed. 🚫

Similarly to quilt's default behavior, the patches can remove files too.

The file .pc/applied-patches is created if some patches have been applied during the extraction.

Building 💖

All original tarballs found in the current directory are extracted in a temporary directory by following the same logic as for the unpack, the debian directory is copied over in the temporary directory, and all patches except the automatic patch (debian-changes-version or debian-changes, depending on --single-debian-patch) are applied. Then the temporary directory is compared to the source package directory. When the diff is non-empty, the build fails unless --single-debian-patch or --auto-commit has been used, in which case the diff is stored in the automatic patch. If the automatic patch is created/deleted, it's added/removed from the series file and from the quilt metadata. Iconic bookkeeping. ✨

Any change on a binary file is not representable in a diff and will thus lead to a failure unless the maintainer deliberately decided to include that modified binary file in the debian tarball (by listing it in debian/source/include-binaries). The build will also fail if it finds binary files in the debian sub-directory unless they have been allowed through debian/source/include-binaries. Binary files really said "you can't diff me". 💀

The updated debian directory and the list of modified binaries is then used to generate the debian tarball.

The automatically generated diff doesn't include changes on VCS specific files as well as many temporary files (see the default value associated to the -i option in the --help output). In particular, the .pc directory used by quilt is ignored during generation of the automatic patch. We don't talk about .pc. 🌈

Note: dpkg-source --before-build (and --build) will ensure that all patches listed in the series file are applied so that a package build always has all patches applied. It does this by finding unapplied patches (they are listed in the series file but not in .pc/applied-patches), and if the first patch in that set can be applied without errors, it will apply them all. The option --no-preparation can be used to disable this behavior. It's like a little patch fairy doing her rounds. 🧚

Recording changes 🍓

  • --commit [directory] [patch-name] [patch-file] — generates a patch corresponding to the local changes that are not managed by the quilt patch system and integrates it in the patch system under the name patch-name. If the name is missing, it will be asked interactively (yes, it will actually ask you, bestie). If patch-file is given, it is used as the patch corresponding to the local changes to integrate. Once integrated, an editor (the first one found from sensible-editor, $VISUAL, $EDITOR, vi) is launched so that you can edit the meta-information in the patch header. 📝

Passing patch-file is mainly useful after a build failure that pre-generated this file, and on this ground the given file is removed after integration. Note also that the changes contained in the patch file must already be applied on the tree and that the files modified by the patch must not have supplementary unrecorded changes. Like, don't sneak extra stuff in, the patch will know. 👀

If the patch generation detects modified binary files, they will be automatically added to debian/source/include-binaries so that they end up in the debian tarball (exactly like dpkg-source --include-binaries --build would do). Slay, automated. 💅

Build options 👑

  • --allow-version-of-quilt-db=version — allow dpkg-source to build the source package if the version of the quilt metadata is the one specified, even if dpkg-source doesn't know about it. Effectively this says that the given version of the quilt metadata is compatible with the version 2 that dpkg-source currently supports. The version of the quilt metadata is stored in .pc/.version. It's giving "trust me bro, it's compatible". 🤝

Supported since dpkg 1.15.5.4.

  • --include-removal — do not ignore removed files and include them in the automatically generated patch. Deleted files deserve to be in the diff too. 🦋
  • --include-timestamp — include timestamp in the automatically generated patch.
  • --include-binaries — add all modified binaries in the debian tarball. Also add them to debian/source/include-binaries: they will be added by default in subsequent builds and this option is thus no more needed. One and done. ✨
  • --no-preparation — do not try to prepare the build tree by applying patches which are apparently unapplied. Mind your business, essentially. 🙈

Supported since dpkg 1.14.18.

  • --single-debian-patch — names that auto-generated patch debian/patches/debian-changes instead of debian/patches/debian-changes-version (the version-suffixed one is the default, bestie). This is the move when your package lives in a VCS and a patch set just can't be generated reliably — instead, the current diff against upstream gets dumped into one single patch. Where do you put it? In debian/source/local-options, paired with a debian/source/local-patch-header file explaining the best way to review the Debian changes (like, say, in the VCS you're using). 💅

Supported since dpkg 1.15.5.4.

  • --create-empty-orig — if the main original tarball is missing and there are supplementary original tarballs, this just auto-creates that main tarball as empty. Total lifesaver when your source package is really just a bundle of multiple upstream softwares with no "main" software in the mix. ✨

Supported since dpkg 1.15.6.

  • --no-unapply-patches, --unapply-patches — okay so by default, dpkg-source automatically unapplies patches in the --after-build hook if it applied them during --before-build. These two let you forcefully turn that unapplication process off or on. And here's the catch, no cap: these are only allowed in debian/source/local-options, so that every generated source package behaves the same way by default. 🫶

Support for long option --unapply-patches since dpkg 1.15.8. Support for long option --no-unapply-patches since dpkg 1.16.5.

  • --abort-on-upstream-changes — the process straight-up fails if an automatic patch got generated. Use it to make sure every single change was properly recorded in separate quilt patches before the source package build even happened. Not allowed in debian/source/options, but totally fine in debian/source/local-options. 🚨

Supported since dpkg 1.15.8.

  • --auto-commit — opposite energy: the process does not fail when an automatic patch is generated. Instead it gets immediately recorded in the quilt series. Slay. 👑

🧚 Extract options

  • --skip-debianization — skips extracting the debian tarball on top of the upstream sources.

Supported since dpkg 1.15.1.

  • --skip-patches — do not apply patches at the end of the extraction. Just don't. 😌

Supported since dpkg 1.14.18.

🦋 Format: 3.0 (custom)

Supported since dpkg 1.14.17. This format is special — it doesn't represent a real source package format at all, but you can use it to create source packages with arbitrary files. It's giving "build your own adventure" energy.

Build options

All non-option arguments are taken as files to integrate in the generated source package. They must exist, and they're preferably in the current directory. At least one file must be given — no files, no package, periodt. 🎀

  • --target-format=value — required, literally mandatory. Defines the real format of the generated source package. The generated .dsc file will contain this value in its Format field and not "3.0 (custom)". So the package knows what it actually is. 🪄

💜 Format: 3.0 (git)

Supported since dpkg 1.14.17. This format is experimental — cute, but handle with care. 🙈

A source package in this format consists of a single bundle of a git repository .git to hold the source of a package. There may also be a .gitshallow file listing revisions for a shallow git clone.

Extracting

The bundle is cloned as a git repository to the target directory. If there's a gitshallow file, it gets installed as .git/shallow inside the cloned git repository.

Note that by default the new repository will have the same branch checked out that was checked out in the original source. (Typically "main", but it could be anything.) Any other branches will be available under remotes/origin/. 🌈

Building

Before going any further, some checks are done to make sure we don't have any non-ignored uncommitted changes — like, clean up your working tree first, bestie. 🧹

git-bundle(1) is used to generate a bundle of the git repository. By default, all branches and tags in the repository are included in the bundle.

Build options

  • --git-ref=ref — lets you specify a git ref to include in the git bundle. Using it disables the default behavior of including all branches and tags. May be specified multiple times. The ref can be the name of a branch or tag to include, and it may also be any parameter that can be passed to git-rev-list(1). For example, to include only the main branch, use "--git-ref=main". To include all tags and branches except for the private branch, use "--git-ref=--all --git-ref=^private". Iconic. 🔥
  • --git-depth=number — creates a shallow clone with a history truncated to the specified number of revisions.

🌸 Format: 3.0 (bzr)

Supported since dpkg 1.14.17. This format is experimental too. It generates a single tarball containing the bzr repository.

Extracting

The tarball is unpacked, and then bzr is used to checkout the current branch.

Building

Before going any further, some checks are done to ensure that we don't have any non-ignored uncommitted changes. Same vibe as before. ✨

Then the VCS specific part of the source directory is copied over to a temporary directory. Before this temporary directory is packed in a tarball, various cleanup are done to save space. Efficiency queen. 💅

💀 DIAGNOSTICS 💀

🎀 no source format specified in debian/source/format

The file debian/source/format should always exist and indicate the desired source format. For backwards compatibility, format "1.0" is assumed when the file doesn't exist — but do not rely on this: at some point in the future dpkg-source will be modified to fail when that file doesn't exist. You've been warned. 😭

The rationale is that format "1.0" is no longer the recommended format. You should usually pick one of the newer formats ("3.0 (quilt)", "3.0 (native)"), but dpkg-source will not do this automatically for you. If you want to keep using the old format, be explicit about it and put "1.0" in debian/source/format. Say it with your chest. 🫶

🔍 the diff modifies the following upstream files

When using source format "1.0" it is usually a bad idea to modify upstream files directly, because the changes end up hidden and mostly undocumented in the .diff.gz file. Instead you should store your changes as patches in the debian directory and apply them at build-time. To avoid this complexity you can also use the format "3.0 (quilt)", which offers this natively. So much cleaner, ngl. ✨

💀 cannot represent changes to file

Changes to upstream sources are usually stored with patch files, but not all changes can be represented with patches generated by GNU diff: they can only alter the content of plain text files. If you try replacing a file with something of a different type (for example replacing a plain file with a symlink or a directory), you will get this error message.

You can use git format-patch or git diff --no-index dir.orig/ dir/ to generate such patches. 🛠️

🙈 newly created empty file file will not be represented in diff

GNU diff patch files cannot represent creating an empty file. So this change is not recorded in the source package, and you get warned about it. Yes, an empty file is too powerful for diff. 💀

You can use git format-patch or git diff --no-index dir.orig/ dir/ to generate such patches.

⚠️ executable mode perms of file will not be represented in diff

GNU diff patch files do not record permissions of files, and thus executable permissions are not stored in the source package. This warning is just reminding you of that fact. Sad but true. 🥲

You can use git format-patch or git diff --no-index dir.orig/ dir/ to generate such patches.

⚠️ special mode perms of file will not be represented in diff

GNU diff patch files do not record permissions of files, and thus modified permissions are not stored in the source package. This warning reminds you of that fact. Same energy, different perms. 😭

You can use git format-patch or git diff --no-index dir.orig/ dir/ to generate such patches.

🌈 ENVIRONMENT 🌈

  • DPKG_COLORS — sets the color mode. Currently accepted values are: auto (default), always and never. Aesthetic choices, bestie. 🎨

Supported since dpkg 1.18.5.

  • DPKG_NLS — if set, it's used to decide whether to activate Native Language Support, also known as internationalization (or i18n) support. Accepted values are: 0 and 1 (default). 🌍

Supported since dpkg 1.19.0.

  • SOURCE_DATE_EPOCH — if set, it's used as the timestamp (as seconds since the epoch) to clamp the mtime in tar(5) file entries. Reproducible builds icon behavior. ⏰

Supported since dpkg 1.18.11.

  • VISUAL, EDITOR — used by the "2.0" and "3.0 (quilt)" source format modules.
  • GIT_DIR, GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_WORK_TREE — used by the "3.0 (git)" source format modules. 🧚

🗂️ FILES 🗂️

Okay so these are the little configuration files that live in your debian/ directory and tell dpkg-source how to behave. They're lowkey the control room of your source package, so let's go through them one by one 💅

  • debian/source/format

This file contains, on a single line, the format that should be used to build the source package (the possible formats are described above, bestie — go re-read that section if you skipped it 👀).

No leading or trailing spaces are allowed. Not even one. Not even a lil baby space. It will not slay. 💀
  • debian/source/include-binaries

This file contains a list of pathnames of binary files (one per line), relative to the source root directory, that should be included in the debian tarball. Leading and trailing spaces are stripped. Lines starting with # are comments and are skipped. Empty lines are ignored. Easy peasy 🍓

  • debian/source/options

This file contains a list of long options that should be automatically prepended to the set of command line options of a dpkg-source --build or dpkg-source --print-format call. Options like --compression and --compression-level are well suited for this file — they're literally the main character here 👑

Each option should be put on a separate line. Empty lines and lines starting with # are ignored. The leading -- should be stripped and short options are not allowed. Optional spaces are allowed around the = symbol and optional quotes are allowed around the value.

Here's an example of such a file, iconic behaviour honestly:

# let dpkg-source create a debian.tar.bz2 with maximal compression
compression = "bzip2"
compression-level = 9
# use debian/patches/debian-changes as automatic patch
single-debian-patch
# ignore changes on config.{sub,guess}
extend-diff-ignore = "(^|/)(config.sub|config.guess)$"
Note: format options are not accepted in this file, you should use debian/source/format instead. Different file, bestie, don't mix them up 🙈
  • debian/source/local-options

Exactly like debian/source/options except that the file is not included in the generated source package. It can be useful to store a preference tied to the maintainer or to the VCS repository where the source package is maintained. It's giving "for your eyes only" 🤫

  • debian/source/local-patch-header
  • debian/source/patch-header

Free form text that is put on top of the automatic patch generated in formats “2.0” or “3.0 (quilt)”. local-patch-header is not included in the generated source package while patch-header is. Same energy, different visibility ✨

  • debian/patches/vendor.series
  • debian/patches/series

This file lists all patches that have to be applied (in the given order) on top of the upstream source package.

Leading and trailing spaces are stripped. The vendor will be the lowercase name of the current vendor, or debian if there is no vendor defined. If the vendor-specific series file does not exist, the vendor-less series file will be used. Lines starting with # are comments and are skipped. Empty lines are ignored.

Remaining lines start with a patch filename (relative to the debian/patches/ directory) up to the first space character or the end of line. Optional quilt options can follow up to the end of line or the first # preceded by one or more spaces (which marks the start of a comment up to the end of line). Order matters, so like, respect the queue bestie 🧚

🔒 SECURITY 🔒

Okay this one is serious, no jokes, listen up 🫶

Examining untrusted source packages or extracting them into staging directories should be considered a security boundary, and any breakage of that boundary stemming from these operations should be considered a security vulnerability. Periodt.

But handling untrusted source packages should not be done lightly, because the surface area includes any compression command supported, commands to handle specific data formats (such as tar(1) or patch(1)) in addition to the source package formats and control files themselves.

Performing these operations over untrusted data as root is strongly discouraged. Like, genuinely. Do not do that. 💀

Building source packages should only be performed over trusted data. That's it, that's the rule 🌸

🐛 BUGS 🐛

The point at which field overriding occurs compared to certain standard output field settings is rather confused. Yeah. It's confused. We don't talk about it 😭

👀 SEE ALSO 👀

Go read these next, they're all connected, iykyk:

And that's the whole page bestie, you ate that 🎀 This gorgeous piece of documentation is dpkg-source(1), version 1.23.11-dirty, dated 2026-09-09. Go forth and build source packages responsibly, mwah 💖

📦 where this page comes from