/etc/portage/patches

User patches provide a way for users to apply patches to ebuilds. This is useful for the rare cases of site-specific patches, but also for testing patches before sending them to upstream or to the Gentoo bug tracker. The feature is provided by many ebuilds, either by calling  explicitly or by inheriting an eclass and relying on its default implementation of. Current Gentoo policy does not require ebuilds to use, its usage is at the package maintainer's discretion. There is also a way to enable it for all ebuilds.

Enabling /etc/portage/patches for all ebuilds
If an ebuild does not call, and you still wish to apply user patches, you can do that using /etc/portage/bashrc and hooks provided by Portage. Candidates are,   or. The first two have the advantage of being run before  (or similar) and the last two have the advantage of being run in the right directory, so only   shares those advantages.

Normally only ebuilds inheriting  can access , so you would need to test for its presence and non-eutils ebuilds wouldn't get patched at all. There's a trick of pulling in only the necessary bits from, running   and dropping them.

With  and the above trick, you don't need to play with changing directories, you can support all ebuilds whether they import   or not, and you get your patches applied as soon as possible in the chain. While it might still be better to have this feature as part of portage, the following snippet should cover everyday needs pretty well.

Adding user patches
First you need to choose the location for your patches, depending on the package name and the versions it is intended for. You can use the following locations plus you can optionally append  to any of them.



Examples:



First you need to create the directory.

Now you have your directory ready and you can drop the patches there. Only files with  suffix are considered and they are applied in the order determined by their name.

Note that  attempts to apply them repeatedly with a prefix stripped up to a different number of slashes.

Using a git directory as a source of patches
Instead of creating the directory, you can create a symlink to a git directory in your system.

Now, in the git directory, you can do your usual work and when you're finished, just remove all the patches from the previous run and use  to create a patchset from your branch based on another known branch.

This solution relies on the fact that only files ending with  are processed in the patch directory.

Adding support for user patches to your ebuilds
It's up to the maintainer of the ebuild to decide when exactly is  called. It would typically be in  together with patches specified in the ebuild itself and the build system actions like. To best accomodate user patches that would later be suitable for submitting upstream, it should be the very first action. Note that without changing the ebuild, the user can only force it to be called earlier, not later.

As a maintainer, you often get  for free by inheriting an eclass. Then it's you who can either force it to be run earlier or rely on the eclass to do that. For example,  calls   after applying other patches in its implementation of.

When the ebuild ends up calling  multiple times (e.g. because the maintainer called it explicitly but also used an eclass that calls it), the first call creates  and subsequent calls have no effect.