1 |
Zac Medico wrote: |
2 |
> Steven J Long wrote: |
3 |
>> It seems there's two major cases, with autotools or without. In either |
4 |
>> case, epatch_user should be called after Gentoo patches have been |
5 |
>> applied. |
6 |
>> |
7 |
>> Why not make epatch_user set a variable to indicate that patches have |
8 |
>> been applied, and only apply the patches on the first call? |
9 |
>> |
10 |
>> Then eautoreconf could call it before calling autoconf (and the ebuild |
11 |
>> wouldn't need to worry about it.) And any custom src_prepare function |
12 |
>> could call it when needed, if it needed to be done during the phase, and |
13 |
>> not after. |
14 |
>> |
15 |
>> After src_prepare, the PM could just call it unconditionally, since it |
16 |
>> will not apply the patches again, if it's already been called by the |
17 |
>> ebuild. |
18 |
>> |
19 |
>> Does that make sense? |
20 |
> |
21 |
> Yeah, sounds roughly equivalent to Ciaran's suggested |
22 |
> "apply_user_patches_here" approach [1], except that Ciaran suggested to |
23 |
> make it an error if src_prepare doesn't call apply_user_patches_here (so |
24 |
> people don't forget to call it when they should). |
25 |
> |
26 |
> [1] |
27 |
> http://archives.gentoo.org/gentoo- |
28 |
dev/msg_c228be85e0c4e577ad194e6004d59062.xml |
29 |
|
30 |
Yeah, I saw that, but given that this would be standardisation around an |
31 |
EAPI bump, I don't see the point in changing the name of the function to |
32 |
mean exactly the same thing, only to make it much more inconvenient in |
33 |
usage. |
34 |
|
35 |
I feel there needs to be more thinking about what you mentioned, ie around |
36 |
the lines of "user-patches are applied on top of Gentoo-patched sources." |
37 |
This makes much more sense in process terms, since user-patches are more |
38 |
likely to be included in Gentoo-patches, and thus easier to handle for |
39 |
submission upstream. The alternative (user-patches applied to vanilla |
40 |
sources) has much more likelihood for bad interaction with Gentoo patches or |
41 |
changes. |
42 |
|
43 |
If we stipulate that src_prepare transforms upstream sources into Gentoo- |
44 |
official sources, then it only makes sense to epatch_user thereafter, and |
45 |
there's no point burdening the ebuild, or its developer, with that task. |
46 |
It also makes ebuilds much cleaner to read. |
47 |
|
48 |
Where you have a build-system that requires epatch_user part way through |
49 |
src_prepare, it's up to the ebuild, or more likely eclass for that build- |
50 |
system, to call it at the appropriate time. (autoconf ebuilds clearly should |
51 |
just inherit whatever eclass the team tells them to, and stop messing |
52 |
around.) |
53 |
|
54 |
In any event, specifying that the PM only calls epatch_user after |
55 |
src_prepare if there are user-patches, and it hasn't been called already |
56 |
(this is easiest done within epatch_user, ofc) allows ebuild or eclass |
57 |
developers to override the default easily, while still keeping things easy |
58 |
for most ebuilds. |
59 |
|
60 |
eg: so far I've heard that: epatch_user && eautoreconf |
61 |
..is desired behaviour, so I guess you want logic like: |
62 |
|
63 |
if ((${#USER_PATCHES[*]})); then |
64 |
((applied_user_patches)) || { |
65 |
<.. apply the patches || die ..> |
66 |
applied_user_patches=1 |
67 |
} |
68 |
return 0 |
69 |
else return 1 |
70 |
fi |
71 |
|
72 |
Given something like the above, the addition of a simple[1]: epatch_user |
73 |
..to eautoreconf before the call to autoreconf, and after src_prepare in |
74 |
ebuild.sh, cannot do any harm, and ensures that sources are patched without |
75 |
adding any cruft to ebuilds. |
76 |
|
77 |
I also think there would be merit in optionally including any user-patches |
78 |
with binpkgs. This would be useful for transparency, ie debugging and |
79 |
licensing concerns with respect to modified sources. |
80 |
|
81 |
Regards, |
82 |
Steve. |
83 |
|
84 |
PS As you know, ofc, patches against vanilla sources can be done in a |
85 |
pre_src_prepare bashrc hook, if one really has to for custom builds. I don't |
86 |
think anyone's talking about implementing them; or should they be on the |
87 |
table too? |
88 |
|
89 |
[1] Yes, EAPI-dependent, so might need eg: |
90 |
case $EAPI in 5|6) epatch_user;; esac |
91 |
..depending on what else is happening, but simple in the sense that we don't |
92 |
care about its return value in these contexts. |
93 |
|
94 |
-- |
95 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |