Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Gentoo Developer Mailing List <gentoo-dev@l.g.o>
Subject: [gentoo-dev] How shall we name the EAPI 6 patch applying function?
Date: Wed, 03 Apr 2013 09:14:32
Message-Id: 20130403111437.4c1e0aa6@pomiocik.lan
1 Hello all,
3 Wrt bug #463692 [1] we'd like to add a default src_prepare() in EAPI 6,
4 with PATCHES array and user patches support. For that reason, I've
5 requested in bug #463768 [2], that the function used to apply
6 the patches would be public -- so that users and eclasses could use it
7 consequently.
9 After some discussion on the relevant bug we came to the conclusion
10 that the epatch function is relentlessly bloated. It provides a lot
11 of features which are either already discouraged by its maintainer
12 (arch-prefixed patches), result in widespread QA issues (compressed
13 patch support) or is just too hard to implement reasonably.
15 For that reason, the new function will most likely support
16 the following:
18 a) patch files can be specified directly or through a directory
19 in which *all* files will be applied in lexical order,
21 b) patches will be applied with -p1 unless overrode via direct
22 arguments to patch applying function.
24 Rationale will follow. Since that functionality is very limited
25 compared to the epatch function, we will keep the old one in the eclass
26 for anyone really needing it. However, we need a name for the new
27 function.
29 Therefore, I ask you: how should we name the new (and simpler) patch
30 applying function which will be provided in EAPI 6?
32 [1]:
33 [2]:
36 Please note that the following rationale is assembled mostly from my
37 opinion and understanding of the others. Please do not take is
38 as an official Gentoo statement.
40 Short rationale:
42 1) automatic -p* support has seen most effort to keep in the spec.
43 However, there are a few important issues with it which outweigh
44 the usefulness of it:
46 * inability to know what intended patchlevel was can result in patches
47 being applied to wrong files (e.g. when patch stops to apply
48 to the intended file or start to apply to an unintended file with
49 a lower patchlevel).
51 * the patches stored in the tree can't be easily reused upstream
52 or by users since 'epatch' is limited to ebuild scope.
54 * the current implementation of epatch results in hard-to-read error
55 output (you have to grep for the 'most proper' run).
57 This also implies that due to a new QA policy, Gentoo tree will consist
58 only of patches adjusted to be used with '-p1'. If nobody steps up
59 earlier, I will write a tool to fix patches to proper patchlevel.
62 2) compressed patch support is likely the most misused feature
63 in epatch. This is because in the most cases it was used:
65 * (in Sunrise overlay) to apply compressed patches from ${FILESDIR} --
66 where storing compressed files there is a violation of QA policy.
68 * to apply compressed patches from ${DISTDIR} -- when src_unpack()
69 has uncompressed the patches to ${WORKDIR} already.
71 Considering that the most compressed patches will either be downloaded
72 as compressed files or compressed archives, the responsibility for
73 unpacking them will fall on src_unpack(). Therefore, we believe that
74 there's no need for additional layer of complexity here.
77 3) support for directories was one of the most obfuscated features
78 of epatch. It included a number of adjustment variables like
79 EPATCH_SUFFIX, EPATCH_FORCE (where nobody could guess its meaning),
80 EPATCH_EXCLUDE and the discouraged arch-prefixed patches.
82 I've taken a quick grep of the Gentoo ebuild tree and the Gentoo patch
83 tree, and it seems that:
85 * only sys-libs/glibc seems to be still using arch-conditional patching.
87 * most of the patch directories consist of files prefixed by ordering
88 number, suffixed by either '.patch' or '.diff'.
90 * some of the patch trees use Debian-style patches. That is, randomly
91 named files with 'series' file determining the order of applying.
93 We've chosen the common solution which will work correctly for most
94 of the ebuilds with no need for additional control variables. Other
95 cases will either need to use globs to choose files directly,
96 or the eclass-defined epatch function.
99 I hope I covered all the main points. If I missed something, please let
100 me know.
102 --
103 Best regards,
104 Michał Górny


File name MIME type
signature.asc application/pgp-signature