kloeri

• startups (everything related to startups / small business and open source software)
• green technology (recycling, monitoring etc.)

Exherbo has a fairly strict patch policy that's usually summarised as "no patches without a damn good reason". Good reasons includes "Compile fixes" and "Security patches" at the very least but we do end up rejecting quite a few proposed patches.

I decided on this policy from the very beginning of Exherbos life as it's much easier working with upstream if we don't add patches against their wishes and it also makes it a lot easier for users to move to another distribution if/when needed (assuming that other distribution haven't patched the application(s) too heavily).

All in all this policy have worked very well for Exherbo so far but what can you do when you really, really want that patch for your favorite application? The first (and in many cases best) option is simply talking to upstream and convincing them that the patch is a good idea. That way all users benefits from the patch regardless of their choice of distribution and upstream takes care of maintainance and QA.

But what can you if that fails or you simply want a patch specifically tailored to your local needs? An easy way to solve that is through the magic of auto patching - paludis makes it quite easy to add local patches to specific packages any time you upgrade/reinstall them using phase hooks.

Below is a generic auto patch hook courtesy of Ciaran McCreesh.

$ cat /etc/paludis/hooks/ebuild_prepare_post/patches.bash
# vim: set sw=4 sts=4 et :

(
    cd "${S}"
    patchdir="/home/users/ciaranm/work/autopatch/${CATEGORY}/${PN}"
    if [[ -d $patchdir ]] ; then
        einfo "Applying user patches"
        for p in $patchdir/*.patch ; do
            [[ -f "${p}" ]] || continue
            einfo "Applying $(basename ${p} )"
            patch -p1 < ${p} || exit 1
        done
        einfo "Done"
    fi
)

Before using this hook you want to change "patchdir" so it points to your own local patch directory. And then you simply add patches (files should be named *.patch) in $category/$packagename directories in your patch directory. As an example you could add a net-www/chromium/omnibar-http.patch file containing the following patch if you want to revert the recent sillyness of not showing http in the omnibar in chromium.

Source: Timothy Redaelli - updated by Elias Pipping
Upstream: Rejected, see http://crbug.com/41885
Reason: Do not strip http:// from omnibar!

--- b/net/base/net_util.cc
+++ a/net/base/net_util.cc
@@ -1452,7 +1452,7 @@
url_string == kHTTP && (!parsed.host.is_valid() ||
(parsed.host.is_nonempty() &&
spec.compare(parsed.host.begin,
- std::string(kFTP).size(), kFTP))));
+ std::string(kFTP).size(), kFTP))) && false);

new_parsed->scheme = parsed.scheme;

Adding local patches is now just a question of dropping the patch file in the correct path but keep in mind that you have the responsibility of maintaining not only your local patch but also anything it might affect (not limited to the patched package).