Config...:Patch(3pm)

📦
version 3.026 · 6 versions
, in ubuntu stonking

💖 Config...:Patch — the Config::Model::models::Dpkg::Patch glow-up 💖

hey bestie!! okay so you know how Debian patches come with all that ✨metadata✨ at the top (the DEP-3 stuff)? This is the Config::Model side of that whole situation — the configuration class that tells cme what a Dpkg::Patch is allowed to look like. Basically it's the vibe check for your patch headers. Let's get into it 🎀

🌸 DESCRIPTION 🌸

These are the configuration classes that Config::Model uses. That's the whole plot, fr fr — it's the machinery that describes the thing so the editor can edit the thing 🦋

✨ Elements ✨

📝 Synopsis — short description of the patch

This line lives in the first line of the DEP-3 description field. No cap.

Optional. Type is uniline. 💅

📖 Description

The verbose explanation of the patch and, like, its whole history — the lore.

Optional. Type is string. 💜

🏷️ Subject

Optional. Type is uniline.

This field holds one URL pointing at the related bug — possibly the one your patch fixes, who knows. The Bug field is reserved for the bug URL in the upstream bug tracker. You can use these fields multiple times if several bugs are in the group chat.

The vendor name is explicitly encoded right in the field name so vendors can share patches with each other without having to go update the meta-information in most cases. The upstream bug URL is special-cased because it's the central point of cooperation and it has to be easily distinguishable from all the other bug URLs, periodt.

Now, to get a vendor bug (like Bug-Foo) in the graphical editor: right-click on the patch name, type "Bug-Foo" (or literally any other value) into the "accept:" entry, and hit Return. A new element gets created that you can fill in just like the Bug field. Iconic behaviour honestly.

Optional. Type is list of uniline. 👑

This field holds one URL pointing at the related bug (possibly fixed by the patch). The Bug-Debian field is reserved for the bug URL in the Debian BTS. These fields can be used multiple times if several bugs are concerned.

Optional. Type is list of uniline. 🍓

📤 Forwarded

Any value other than "no" or "not-needed" means the patch has been forwarded upstream. Ideally the value is a URL proving it was forwarded and where someone can find more info about its inclusion status — receipts, basically.

If the field is missing, its implicit value is "yes" if the Bug field is present, otherwise it's "no". The field is really required only if the patch is vendor specific — in that case its value should be "not-needed" to say the patch must not be forwarded upstream (whereas "no" simply means it hasn't been done yet). Big difference, don't mix them up 😭

Optional. Type is uniline. 🌈

✍️ Author

This field can record the name and email of the patch author (ex: "John Bear <foo@example.com>"). Its usage is recommended when the patch author didn't add copyright notices for their work in the patch itself. It's also a good idea to add this contact info when the patch needs to be maintained over time because it has, like, very little chance of being integrated upstream. This field can be used multiple times if several people authored the patch.

Optional. Type is list of uniline. 💖

🗺️ Origin

This field should document the origin of the patch. In most cases it should be a simple URL. For patches backported/taken from upstream, it should point into the upstream VCS web interface when possible; otherwise it can simply list the relevant commit identifier (and it should be prefixed with "commit:" in that case). For other cases, you should simply indicate the URL where the patch was taken from (mailing list archives, distribution bugtrackers, etc.) when possible.

The field can optionally be prefixed with a single keyword followed by a comma and a space, to categorize the origin. The allowed keywords are:

  • "upstream" — for a patch cherry-picked from the upstream VCS
  • "backport" — for an upstream patch that had to be modified to apply on the current version
  • "vendor" — for a patch created by Debian or another distribution vendor
  • "other" — for all other kinds of patches

In general, a user-created patch grabbed in a BTS should be categorized as "other". When copying a patch from another vendor, the meta-information (and hence this field) should be kept if present, or created if necessary with a "vendor" origin.

If the Author field is present, the Origin field can be omitted and it's assumed the patch comes from its author.

Optional. Type is string. 🧚

📨 From

Like the Author field, this one can record the name and email of the patch author (ex: "John Bear <foo@example.com>"). Its usage is recommended when the patch author didn't add copyright notices for their work in the patch itself. It's also a good idea to add this contact info when the patch needs to be maintained over time because it has very little chance of being integrated upstream. This field can be used multiple times if several people authored the patch.

Optional. Type is list of uniline. 💜

👀 Reviewed-by

This field can document the fact that the patch has been reviewed and approved by someone. It should list her name and email in the standard format (similar to the example given for the Author field). This field can be used multiple times if several people reviewed the patch.

Optional. Type is list of uniline. ✅

👍 Acked-by

Synonym to Reviewd-by. (yes the original really spells it like that, we're keeping it verbatim, don't @ me 💀)

This field can document the fact that the patch has been reviewed and approved by someone. It should list her name and email in the standard format (similar to the example given for the Author field). This field can be used multiple times if several people reviewed the patch.

Optional. Type is list of uniline. 🫶

📅 Last-Update

This field can record the date when the meta-information was last updated. It should use the ISO date format YYYY-MM-DD.

Optional. Type is uniline. ⭐

🚀 Applied-Upstream

This field can document the fact that the patch has been applied upstream. It may contain the upstream version expected to contain this patch, or the URL or commit identifier of the upstream commit (with commit identifiers prefixed with "commit:", same as in the Origin field), or both of those separated by a comma and a space.

Optional. Type is uniline. 🔥

🩹 diff — actual patch

This element contains the actual diff that'll be used to patch the source.

⚠️ Do not modify unless you really know what you're doing. Like, genuinely. This is the main character of the whole file and you are not the director. 😭

Optional. Type is string. 💅

🌈 SEE ALSO 🌈

  • cme — the editor that reads all this 💖

k that's the whole page bestie!! this one's from perl v5.42.3, dated 2026-08-30 — go forth and annotate your patches with impeccable DEP-3 energy 🎀✨🦋💖

📦 where this page comes from