/etc/portage/patches

User patches provide a way for users to apply patches to package source code if the ebuild provides this feature. Ebuilds cannot be patched by this. This is useful for applying upstream patches to unresolved bugs and for the rare cases of site-specific patches.

EAPI 6

 * The ebuild does not have src_prepare
 * The ebuild has src_prepare with  in the first line
 * The ebuild has src_prepare with

EAPI 5 and older

 * The ebuild is calling  explicitly
 * The ebuild is inheriting an eclass and relying on its default implementation of

Adding user patches
First choose the location for the patches, depending on the package name and the version(s) it is intended for. Use the following locations and optionally append  to any of them:



Examples:



Example
An example shows how to easily apply an upstream patch for of.

The affected version of that package is 1.2.5 and upstream provides the patch for it but has not yet released a new version.

For applying the patch from upstream, the appropriate directory needs to be created:

Next, an arbitrarily named file with suffix has to be dropped here with the content provided from upstream:

{{FileBox|filename={{path|/etc/portage/patches/x11-misc/pcmanfm-1.2.5/CVE-2017-8934.patch}}|1= * Removed options to Cut, Remove and Rename from context menu on mounted diff --git a/src/single-inst.c b/src/single-inst.c index 62c37b3..aaf84ab 100644 (file) --- a/src/single-inst.c +++ b/src/single-inst.c @@ -2,7 +2,7 @@ *     single-inst.c: simple IPC mechanism for single instance app * *      Copyright 2010 Hong Jen Yee (PCMan)  - *     Copyright 2012 Andriy Grytsenko (LStranger)  + *     Copyright 2012-2017 Andriy Grytsenko (LStranger)  * *      This program is free software; you can redistribute it and/or modify *     it under the terms of the GNU General Public License as published by @@ -404,11 +404,16 @@ static void get_socket_name(SingleInstData* data, char* buf, int len) }    else dpynum = 0; +#if GLIB_CHECK_VERSION(2, 28, 0) +   g_snprintf(buf, len, "%s/%s-socket-%s-%d", g_get_user_runtime_dir, +               data->prog_name, host ? host : "", dpynum); +#else g_snprintf(buf, len, "%s/.%s-socket-%s-%d-%s",                g_get_tmp_dir,                 data->prog_name,                 host ? host : "",                 dpynum,                 g_get_user_name); +#endif } }}
 * 1) index 8c2049a..876f7f3 100644 (file)
 * 2) --- a/NEWS
 * 3) +++ b/NEWS
 * 4) @@ -1,3 +1,7 @@
 * 5) +* Fixed potential access violation, use runtime user dir instead of tmp dir
 * 6) +    for single instance socket.
 * 7)  Changes on 1.2.5 since 1.2.4:
 * 1)  Changes on 1.2.5 since 1.2.4:
 * 1)  Changes on 1.2.5 since 1.2.4:

For testing, step into the package's ebuild directory and run the :

With the message "User patches applied." all is good and the package needs to be re-emerged as normally.

Once the patch gets merged to the ebuild repository, do not forget to remove it from the directory. Otherwise next time compiling the ebuild might fail.

Using a git directory as a source of patches
Instead of creating the directory, a symlink can be created to a git directory on the system.

Now, in the git directory, perform the usual work. After finishing remove all patches from the previous run and use git format-patch to create a patchset from the branch based on another known branch.

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

Enabling /etc/portage/patches for all ebuilds
If an ebuild does not call, but user patches are still needed to be applied, it is possible to use /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 one would need to test for its presence and non-eutils ebuilds would not get patched at all. There is a trick of pulling in only the necessary bits from, running  and dropping them.

With  and the above trick, changing directories do not need to be played with, all ebuilds can be supported whether they import   or not, and the patches will 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.

TortoiseGit and Git for Windows
Patches generated by [//tortoisegit.org/docs/tortoisegit/tgit-dug-patch.html Tortoise Git] and Git for Windows are padded with additional information that  does not understand.

The individual generating the patch has to strip these

Nesting
If the file(s) being patched are not unpacked into the root of the working directory,, but rather some sub-directory of the working directory, , then the patch must either be placed in a sub-directory relative to the root,

or it must be modified to accommodate it.

External resources

 * eutils.eclass: Disable epatch_user in EAPI 6. - EAPI 6 has eapply_user which should be used instead.
 * The Ultimate Guide to EAPI 6
 * Patching with epatch - Patching within ebuilds, from devmanual.gentoo.org
 * How to write clean patches when not using git-format-patch.