DPATCH(1)

πŸ“¦ version 2.0.41, in ubuntu jammy

πŸ’– dpatch(1) β€” the patch maintenance system for Debian, but make it make sense πŸ’–

okay bestie, sit down, grab a strawberry πŸ“, because we're talking about dpatch β€” a patch maintenance system for Debian β€” and honestly? she's an icon, even if she's a little vintage.


✨ NAME ✨

dpatch β€” patch maintenance system for Debian


🌸 SYNOPSIS 🌸

dpatch [options] command [command-arguments]

πŸ¦‹ DESCRIPTION πŸ¦‹

so dpatch is an easy to use patch system for Debian packages, and it's somewhat similar to the dbs package, but much simpler to use. no cap. it's giving "I do the same thing but I don't make you read a novel first" πŸ’…

It lets you store patches and other simple customization templates in debian/patches, and otherwise it does not require much reorganization of your source tree. literally the bare minimum, and we respect that.

To get the patches applied at build time you simply need to include a makefile snippet and then depend on the patch/unpatch target in the build or clean stage of debian/rules. and for added flexibility, you can call /usr/bin/dpatch directly too. main character energy fr fr ✨


πŸ’€ WARNING πŸ’€

dpatch is deprecated, please switch to the 3.0 (quilt) Debian source package format instead. See http://wiki.debian.org/Projects/DebSrc3.0#FAQ for a short guide on how to do it.

not me having to tell you this 😭 she's still here, she still works, but the 3.0 (quilt) format is the moment now. go look at that FAQ, it's short, I promise.


πŸ‘‘ GLOBAL OPTIONS πŸ‘‘

There are a few options which change the overall behaviour of dpatch, and have an effect on not only one, but most of the available commands. so like, they're the ones running the group chat, not just replying in it 🫢

These global options are:

  • --workdir (-d) DIRECTORY β€” By default, dpatch applies patches to the source tree it was run from. With this option, one can change that, and tell dpatch to work on a different tree, although taking the dpatches from the current one.
Note that this will only pass a second argument to dpatch scriptlets, and will not change to the specified directory. To do that, use the --chdir option explained below. okay? don't get caught out πŸ’…
  • --chdir (-c) β€” When using a different working directory than the current one, change there before trying to apply patches.
This should be used together with the --workdir option. they're a duo, a package deal, iconic πŸŽ€
  • --strict (-S) β€” Enable strict mode, which means that dpatch will bail out early even on warnings (like when trying to apply a patch which is already applied β€” normally it will simply skip it). she said no chill today 😀
  • --force (-F) β€” Force the application or deapplication of patches, even if dpatch would normally skip them because the operation was already done earlier. do it anyway. periodt.
  • --with-cpp β€” Force the use of cpp. Overrides use of DPATCH_OPTION_CPP=1 option in debian/patches/00options file. yes this really does override it, it's the final word πŸ”₯

🌈 COMMANDS 🌈

🧚 Patch handling commands

There is a generic syntax for all patch handling commands, namely that, that the command itself takes a list of dpatch names to work with, then does what it is meant to do on all of them, in the exact same order it was specified on the command line. order matters bestie, do not shuffle πŸ’–

Then, there is a version of each patch handling command with an -all suffix, which does not take any arguments, and performs the necessary action for each and every available dpatch. all of them. every single one. no survivors, no leftovers πŸŽ€

The last variation is a command with a -until or -up-to suffix, which takes only one argument: the name of a dpatch. The appropriate action will be performed on all dpatches up to and including this specified one. yes, inclusive, we're not being rude about it ✨

⭐ apply [options] / patch [options]

Applies one or more dpatches to the working tree (the current directory, if not told otherwise). By default the specified patches will be applied in the exact same order they were specified.

Options

  • --stampdir=directory, -s=directory β€” Put stamp files into directory instead of the default debian/patched.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything.
  • --verbose (-v) β€” Disables hiding of the scriptlet output.

⭐ deapply [options] / unpatch [options]

Deapplies one or more dpatches to the working tree (the current directory, if not told otherwise). By default the specified patches will be deapplied in the reverse order they were specified as one generally should deapply in reverse order (compared to the apply order, that is). yes, backwards. you undo things in the order you'd take off an outfit, not the order you put it on πŸ’…

Options

  • --stampdir=directory, -s=directory β€” Use stamp files in directory instead of the default debian/patched.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything.
  • --verbose (-v) β€” Disables hiding of the scriptlet output.

⭐ cat [options]

Print meta-information about a dpatch, such as its name, author and description (any of which can be disabled with the appropriate option). it's the "who made this and why" command and honestly it's so useful 🫢

Options

  • --no-meta, --desc-only (-nm, -d) β€” Only print the patch description.
  • --author-only (-a) β€” Only print the author of the patch.
  • --no-desc, (-nd) β€” Do not print the patch description.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything.

⭐ list [options]

List the name of the given patches. This commands is not really useful, except the list-all variant, which lists all available patches. yeah she said it herself, regular list is lowkey pointless, but list-all? that one ate πŸ”₯

Options

  • --help (-h) β€” Print a short help message about the command.

⭐ status [options]

Prints the status of the given patches β€” whether they are applied to the working tree or not. the vibe check command, essentially 🌸

Options

  • --stampdir=directory, -s=directory β€” Use stamp files in directory instead of the default debian/patched.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything.

⭐ log [options]

Displays the log of the given patching attempts. the receipts πŸ“œ

Options

  • --stampdir=directory, -s=directory β€” Use stamp files in directory instead of the default debian/patched.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything, but the logs without extra sugar on top.

⭐ call [options]

Call a dpatch with a user-specified argument. All arguments with a pkg- prefix is guaranteed to be unused by dpatch itself, and are reserved for use with this very command. so if you see pkg- anything, that's yours, that's your lane, go wild πŸŽ€

This command is most useful for extracting custom meta-information from dpatch scriptlets. iykyk πŸ’…

Options

  • --argument=arg (-a=arg) β€” Call patches with arg as argument.
  • --help (-h) β€” Print a short help message about the command.
  • --quiet (-q) β€” Forces the command to not print anything.

πŸ“ Miscellaneous commands

⭐ patch-template [options] [patchname] [description]

Print a quasi-standard dpatch script template, based on the information give on the command-line. If a description given, it will be folded at about 72 characters into multiple lines appropriately. so pretty, so tidy, so organized πŸŽ€

When prepending the template to STDIN, the contents of the standard input will be printed right after the template.

Options

  • --prepend (-p) β€” Prepend the template to STDIN.
  • --help (-h) β€” Print a short help message about the command.

⭐ help (--help, -h) [command]

Attempt to give a little more detailed help about dpatch itself, or about a given dpatch command. she's here for you, she'll explain 🫢

⭐ version

Prints the dpatch version number and exits. short, sweet, iconic πŸ‘‘


and that's part one bestie β€” more is coming, don't go anywhere πŸ’–

🌈 DPATCH IN DEBIAN PACKAGES 🌈

okay bestie so there are two whole ways to use dpatch inside debian/rules:

  1. call it directly
  2. include dpatch.make(7)

and we're only spilling the tea on the first one here β€” the dpatch.make(7) method has its own manual page, so go read that one if that's your vibe. πŸ’…

NOTE: all the examples below also need you to add the .NOTPARALLEL flag to the head of debian/rules, because the dependency lists rely on the order of execution. Without .NOTPARALLEL, the execution order may be wrong when you've got multiple make threads going (that's the -j option). so like... do not skip this step, fr fr. 😭

In most situations you're gonna want to run dpatch as soon during the build process as possible. How you pull that off depends heavily on the debian/rules you already have. But in common practice, most packages have a build (or build-stamp), config.status, or configure (or configure-stamp) target. The easiest way to make dpatching the very first thing is: write a rule that calls dpatch, and add it to the list of prerequisites for the appropriate target (see above). slay. ✨

Deapplying dpatches can be easy, or it can be a bit more tricky β€” it's giving "depends on your setup". If nothing in the clean rule touches files modified by dpatches (which would create incompatible changes), you can safely add unpatch to the list of the clean rule's dependencies. easy peasy. πŸ“

But if the patches might affect the build system, they should be deapplied after the source tree has been cleaned. To do that: rename the clean target to, say, clean-patched, write a rule that calls dpatch to deapply the dpatches, and make a new clean rule that has clean-patched and unpatch as its prerequisites. lowkey iconic, highkey necessary. πŸ‘‘

Let us look at an example! First, the relevant parts of the original debian/rules of our imaginary package:

config.status: configure
     ./configure --prefix=/usr --mandir=/usr/share
build: config.status
     ${MAKE}
clean:
     $(testdir)
     $(testroot)
     ${MAKE} distclean
     rm -rf debian/imaginary-package debian/files debian/substvars

After dpatchifying, this would look like this:

config.status: patch configure
     ./configure --prefix=/usr --mandir=/usr/share
build: config.status
     ${MAKE}
clean: clean-patched unpatch
clean-patched:
     $(testdir)
     $(testroot)
     ${MAKE} distclean
     rm -rf debian/imaginary-package debian/files debian/substvars

patch: patch-stamp
patch-stamp:
     dpatch apply-all
     dpatch cat-all >patch-stamp

unpatch:
     dpatch deapply-all
     rm -rf patch-stamp debian/patched

πŸŽ€ Adding dpatch scriptlets to a package πŸŽ€

When you're using dpatch, you obviously wanna tell the system what dpatches to apply, and which ones to discard. In the most common situation, you only need to list the names of the dpatches (the filenames relative to debian/patches) in debian/patches/00list. They usually have the extension .dpatch and the extension can be omitted β€” so a file debian/patches/01_one_patch.dpatch is written as 01_one_patch inside debian/patches/00list. periodt. πŸ’–

But sometimes you need something more flexible, like applying the same patch on only two architectures, say, m68k and powerpc. You can solve this in at least two very different ways:

  • list the same patch in both debian/patches/00list.m68k and debian/patches/00list.powerpc
  • use DPATCH_OPTION_CPP=1 in debian/patches/00options

When you go the cpp route, the 00list file gets passed through the cpp command with the DEB_BUILD_ARCH variable set to the architecture, and DEB_BUILD_ARCH_architecture being set to 1. With cpp, our sample debian/patches/00list might look like this:

01_manpage_typo
#if defined(DEB_BUILD_ARCH_m68k) || defined(DEB_BUILD_ARCH_powerpc)
/* This patch fixes a random build-time breakage on Macintosh boxen. */
02_macintosh_foo
#endif

πŸ¦‹ Creating dpatch scriptlets πŸ¦‹

There are many ways to create dpatch scriptlets, bestie. They're simple, executable files that follow a standardised calling convention (documented over in dpatch(7)). πŸ’œ

You can fire up your $EDITOR, or use dpatch-edit-patch, and you should be all set. main character energy. ✨

For most cases, where the dpatch file is only meant to apply a simple patch, there's an even easier way:

dpatch patch-template -p "01_some_patch" "A random patch" \
     <random.diff >debian/patches/01_some_patch.dpatch

πŸ“ FILES πŸ“

  • debian/patches/00list β€” the list of patches to apply, deapply, or otherwise fiddle with.
  • debian/patches/00list.arch β€” list of patches to work with additionally to the common list in debian/patches/00list, when building on the arch architecture.
  • /etc/dpatch.conf β€” system-wide configuration file for dpatch, for setting global options permanently.
  • ~/.dpatch.conf β€” per-user configuration file, for setting global options permanently.

πŸ‘‘ AUTHORS πŸ‘‘

dpatch was written by Joerg Jaspert, David B Harris, Gergely Nagy, Junichi Uekawa and others. legends only. 🫢

This manual page was written by Gergely Nagy, and updated by Junichi Uekawa.


πŸ” SEE ALSO πŸ”

dpatch(7), dpatch.make(7), dpatch-edit-patch(1), dpatch-list-patch(1), dpatch-convert-diffgz(1)


and that's the whole page, bestie!! πŸ’–βœ¨πŸŽ€ this one's DPATCH version 2, dated Dec 13 2011 β€” yeah she's a vintage queen but she still ate πŸ‘‘πŸ’… go forth and dpatch responsibly πŸ¦‹

πŸ“¦ where this page comes from