Add a Patches Directive to Allow Custom Patching on top of the Source Tree
Metadata
Current evaluation
Feature request for a native `patches` part key applying local patches during pull. Maintainer steinbro backs the motivation but proposed a Git-native, override-pull-based design; linked PR #1588 still under review.
Suggested action: keep open
Reason: grepping the pinned tree shows no `patches` key in craft_parts/parts.py, part_handler.py, or docs — the feature is unimplemented, and the linked metallb-rocks workaround (`git am` in override-build plus a `plugin: dump` part) is a real workflow pain. However, steinbro explicitly redirected the design ('The patch scheme used in Debian is probably not something to emulate... better accomplished by taking advantage of Git itself', and 'override-pull makes more sense than override-build'), so the accepted spec is unsettled, which caps actionability despite PR #1588 existing with unresolved review feedback.
Evaluated by: mr-cal-bot
Impact:
52
Quick Win:
11
Complexity:
57
Confidence:
80
Actionability:
47
Issue body
### What needs to get done
It would be beneficial if there were a patching mechanism native to the craft-parts library such that when building an artifact, for example a rock, you could define custom patches that you would like to apply atop the source from which you are pulling. This can be useful for local development, as well as performing and testing backports.
### Why it needs to get done
In particular, sometimes customers hit issues in supported and released artifacts and we need to provide them with a patched version of the product. It can be messy to have loose patches floating around and then manually overriding the build to apply the patches. For example: see [this commit](https://github.com/canonical/metallb-rocks/commit/efed043c6655e05d7817db0638c61e071ec714a1#diff-61a282cc92dd2d8e7179253df11385f89e43dbe6dfef59cdebbe206dcac22c9a) to patch a rock, where the patch had to be added and specified in override-build. Note how the patch had to be manually applied with
```
git am /root/parts/patches/src/0001-L2Status-controller-refactor-to-leader-node.patch
```
After also being manually dumped into the build container with a separate part defined by
```
patches:
plugin: dump
source: .
```
Fortunately in this case, there was already an override-build section. However, if there wasn't already such a section, it could be difficult to figure out the correct expected build steps that the plugin applies by default and ensure the patch is applied at the right time.
The proposal of this idea is to add a patches directive that takes a list of patches that are present locally and automatically apply them in the defined order during the pull stage. This is more coherent with the Debian packaging process where distro patches are added to `debian/patches/`, and the order of patch application adheres to the list of patches defined in `debian/patches/series`
Maybe this functionality could also be extended to take in patches from remote sources or the local git tree, and the identifier could be a url, commit hash, or branch name (if all the patches were to be put in one branch). However, such extensibility would be quite complex and may require work to determine the details. For now, local patches would be a great start
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
52
Quick Win:
11
Complexity:
57
Confidence:
80
Actionability:
47
|
keep open | Feature request for a native `patches` part key applying local patches during pull. Maintainer steinbro backs the motivation but proposed a Git-native, override-pull-based design; linked PR #1588 still under review. | |
| stealth/space-bunny-alpha |
Impact:
48
Quick Win:
7
Complexity:
68
Confidence:
72
Actionability:
45
|
keep open | Feature request from an external contributor to add a `patches` part property applying local patches to sources during pull. Maintainer steinbro agreed on the motivation but pushed back on the Debian-style approach, preferring git-based patching via override-pull; design still under discussion. | |
| qwen/qwen3.6-35b-a3b |
Impact:
40
Quick Win:
14
Complexity:
50
Confidence:
75
Actionability:
70
|
keep open | Feature request to add a patches directive to craft-parts for applying custom patches during the pull stage. Maintainer acknowledged motivation but wants to discuss implementation details. | |
| qwen/qwen3.8-27b |
Impact:
45
Quick Win:
18
Staleness:
45
Complexity:
60
Confidence:
80
Support Request:
10
|
keep open | Feature request for a patches directive to apply local patches to the source tree during the pull stage. A maintainer gave design feedback (prefer git-based approach, override-pull), and PR #1588 is open to implement it with unresolved review comments. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
30
Complexity:
60
Confidence:
75
Support Request:
10
|
needs triage | Feature request to add a native patches directive to craft-parts for applying custom patches during the pull stage. Currently under discussion with a maintainer suggesting Git-based approaches and override-pull instead. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
45
Complexity:
65
Confidence:
85
Support Request:
10
|
needs triage | Proposal to add a native patches directive to craft-parts for applying custom patches during the pull stage. Currently open with one maintainer comment suggesting Git-based implementation and further discussion. |
Update history
No update history recorded yet.
Related work
-
Likely Fixed By:
canonical/craft-parts#1588
(confidence 60%)
Open PR 'Add Patches Directive' implements patches during the pull stage, but has 6 unresolved review comments (including hardcoded -p1) and failing CI, so the design steinbro prefers may not match.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1588 Add Patches Directive | craft-parts | open | Adds a `patches` part property to apply patch files over the source tree during pull. Approved once, but 6 unresolved comments, 13 failing checks (all test-common suites), and maintainer wants the hardcoded -p1 design revisited. |