### 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