1 |
Hello everyone, |
2 |
|
3 |
People using nontrivial calls to epatch(), please test this. Also cc'ing |
4 |
Azarah, the author of epatch(). Please comment. |
5 |
|
6 |
Currently there are two patch helper functions - epatch() from eutils.eclass |
7 |
and autopatch in base_src_unpack (inherited by kde.eclass). Each has its own |
8 |
strengths and weaknesses. |
9 |
|
10 |
Briefly, epatch can autodetect the patchlevel (ie -p0, -p1 etc) and handles |
11 |
directories containing many patches well. However, it runs patch --dry-run |
12 |
once or more for each patch, and so takes a long time (for big patchsets) to |
13 |
determine how to apply a patch. |
14 |
|
15 |
autopatch OTOH doesn't do anything special, but is called automatically from |
16 |
base_src_unpack to patch from the files listed in $PATCHES, which allows us |
17 |
not to define an src_unpack() in an ebuild just to patch things. This is very |
18 |
useful in kde ebuilds where we can usually avoid defining any functions at |
19 |
all. |
20 |
|
21 |
I've written xpatch() to unite the strengths of these two schemes (also adding |
22 |
some new stuff) and replace them both. I've committed an initial version into |
23 |
eutils.eclass. It accepts as arguments any amount of patchfiles and/or |
24 |
directories which are scanned for patchfiles (non-recursively, to match |
25 |
epatch's behaviour). In the latter case, only patches whose filenames contain |
26 |
_$ARCH_ or _all_ are applied, to match the most common epatch() usage. |
27 |
|
28 |
The benefit on the user side of all this is faster patching in ebuilds that |
29 |
use e/xpatch - two or three times faster, at least in terms of cpu time. |
30 |
|
31 |
I've tested it with simple ebuilds that only need one patch at -p0 or -p1, and |
32 |
with the xfree ebuild and its patchdir. Just replace any calls to epatch with |
33 |
xpatch. Most/all of the parameters to epatch (via E* variables) aren't needed |
34 |
anymore. |
35 |
|
36 |
One further note: xpatch's test are rather fuzzy. Some (highly improbable imho |
37 |
;-) configs might in theory not work with it. However any such problems would |
38 |
be seen by the developer before committing the ebuild. So I don't want to |
39 |
complicate the function with various special-case checks until someone tells |
40 |
me they're needed in real-world cases. |
41 |
|
42 |
Known issues (both of these can be fixed if requested): |
43 |
- only supports unified-style diffs (because it parses the patchfiles itself a |
44 |
bit). |
45 |
- the first file addressed in a patch can't have a space in its name or |
46 |
relative path (because I'm lazy). |
47 |
|
48 |
Current features (a few more planned): |
49 |
- patchdir handling like epatch's |
50 |
- automatic patchlevel detection like epatch's, but doesn't use --dry-run so |
51 |
takes almost no time |
52 |
- automatic patch uncompression from bzip2, gzip and zip at need. detection of |
53 |
compression is done by calling /usr/bin/file - better than epatch's file |
54 |
extension detection |
55 |
- can be called from autopatch to be used automatically from all existing kde |
56 |
ebuilds that use $PATCHES |
57 |
|
58 |
-- |
59 |
Dan Armak |
60 |
Gentoo Linux developer (KDE) |
61 |
Matan, Israel |
62 |
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key |