Hello everyone,

People using nontrivial calls to epatch(), please test this. Also cc'ing 
Azarah, the author of epatch(). Please comment.

Currently there are two patch helper functions - epatch() from eutils.eclass 
and autopatch in base_src_unpack (inherited by kde.eclass). Each has its own 
strengths and weaknesses.

Briefly, epatch can autodetect the patchlevel (ie -p0, -p1 etc) and handles 
directories containing many patches well. However, it runs patch --dry-run 
once or more for each patch, and so takes a long time (for big patchsets) to 
determine how to apply a patch.

autopatch OTOH doesn't do anything special, but is called automatically from 
base_src_unpack to patch from the files listed in $PATCHES, which allows us 
not to define an src_unpack() in an ebuild just to patch things. This is very 
useful in kde ebuilds where we can usually avoid defining any functions at 
all.

I've written xpatch() to unite the strengths of these two schemes (also adding 
some new stuff) and replace them both. I've committed an initial version into 
eutils.eclass. It accepts as arguments any amount of patchfiles and/or 
directories which are scanned for patchfiles (non-recursively, to match 
epatch's behaviour). In the latter case, only patches whose filenames contain 
_$ARCH_ or _all_ are applied, to match the most common epatch() usage.

The benefit on the user side of all this is faster patching in ebuilds that 
use e/xpatch - two or three times faster, at least in terms of cpu time.

I've tested it with simple ebuilds that only need one patch at -p0 or -p1, and 
with the xfree ebuild and its patchdir. Just replace any calls to epatch with 
xpatch. Most/all of the parameters to epatch (via E* variables) aren't needed 
anymore.

One further note: xpatch's test are rather fuzzy. Some (highly improbable imho 
;-) configs might in theory not work with it. However any such problems would 
be seen by the developer before committing the ebuild. So I don't want to 
complicate the function with various special-case checks until someone tells 
me they're needed in real-world cases.

Known issues (both of these can be fixed if requested):
- only supports unified-style diffs (because it parses the patchfiles itself a 
bit).
- the first file addressed in a patch can't have a space in its name or 
relative path (because I'm lazy).

Current features (a few more planned):
- patchdir handling like epatch's
- automatic patchlevel detection like epatch's, but doesn't use --dry-run so 
takes almost no time
- automatic patch uncompression from bzip2, gzip and zip at need. detection of 
compression is done by calling /usr/bin/file - better than epatch's file 
extension detection
- can be called from autopatch to be used automatically from all existing kde 
ebuilds that use $PATCHES

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key