1 |
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: |
2 |
|
3 |
> On 04/26/2012 02:55 AM, Duncan wrote: |
4 |
>> Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: |
5 |
>> |
6 |
>>> On 04/25/2012 11:18 PM, Duncan wrote: |
7 |
>>>> IOW, let's quit letting the perfect be the enemy of the good |
8 |
|
9 |
>>> If that means settling on something that's fragile and prone to lots |
10 |
>>> of bug reports, then it's not really practical |
11 |
|
12 |
>> IMO[,] If all it does is the patching, but it /always/ does the |
13 |
>> patching[,] and people know they need to use the overlay-ebuild |
14 |
>> method to do anything beyond patching, [including eautoreconf,] |
15 |
>> then it should "just work". |
16 |
|
17 |
> Ignoring the problem doesn't make it go away. If we ignore the problem, |
18 |
> then we end up dealing with bug reports of the form "FEATURES=userpatch |
19 |
> doesn't work with this particular patch set" until the end of time. |
20 |
|
21 |
Standard boilerplate resolved/DUP, pointing to the first one, resolved |
22 |
like this: |
23 |
|
24 |
NOTABUG/INVALID. The feature does what it says on the label and is |
25 |
working as designed. The files are patched and the build bails out if |
26 |
the patch fails. The userpatch feature is deliberately limited to |
27 |
patching, thus keeping the problem manageable and the code transparent |
28 |
and maintainable. For anything fancy, including patches that need |
29 |
eautoreconf called afterward, the userpatch feature isn't the right |
30 |
tool. Copy the ebuild to an overlay and edit it as necessary to both |
31 |
apply the patch and eautoreconf or whatever else needs done afterward. |
32 |
|
33 |
> Also, don't forget to consider the possibility of interference between |
34 |
> FEATURES=userpatch and epatch_user (applying same patches twice). |
35 |
|
36 |
The existing phaselock-file solution should continue to work there. Test |
37 |
for the existence of a file and punt if it's found; touch the file on |
38 |
first invocation. |
39 |
|
40 |
The only caveat is that the existing eclass solution has changed the |
41 |
filename before. Once the corresponding feature exists, both the eclass |
42 |
and the feature will have to use the same filename so as not to conflict |
43 |
with each other, thereby effectively locking down the name and preventing |
44 |
further changes to it. |
45 |
|
46 |
> Overall, the "apply_user_patches_here" approach [1] seems pretty |
47 |
> reasonable to me. |
48 |
> |
49 |
> [1] |
50 |
> http://archives.gentoo.org/gentoo-dev/ |
51 |
msg_c228be85e0c4e577ad194e6004d59062.xml |
52 |
|
53 |
With the requirements that if the ebuild never calls it, it's still run |
54 |
immediately after source_prepare, thus ensuring that it gets called, AND |
55 |
that calling either autoreconf or eautoreconf without calling apply-user- |
56 |
patches first is a repoman-checked error, it looks like it should work, |
57 |
agreed. |
58 |
|
59 |
But I'm a bit wary as to the robustness. And without a mechanism to |
60 |
apply the patches at a particular point (arguably, post-src-prepare) even |
61 |
in the absence of a specific apply-user-patches-here call, we're back |
62 |
where we were without a global solution, but if the hard-invocation is |
63 |
done, then we're back to either inefficiently running eautoreconf twice |
64 |
or forced into doing likely failure-prone detection, thus the worry over |
65 |
robustness. |
66 |
|
67 |
But of course he who codes, decides. We have existing and already proven |
68 |
code for the simple case, but if someone actually codes that complex |
69 |
approach, and it actually does both get us global coverage and avoid |
70 |
duplicated autoreconf runs, without hard to track down failures, I for |
71 |
one will certainly bless them! =:^) |
72 |
|
73 |
I just don't want to have to wait until kingdom come for the "perfect" |
74 |
solution, when we already have a demonstrated "good enough 80-90% of the |
75 |
time" solution ready to roll out globally, if we'd just do it. |
76 |
|
77 |
It's also worth pointing out that nothing prevents rolling out the "good |
78 |
enough" solution right away, then growing the complexity to cover the |
79 |
harder autoreconf cases when a solution for them actually gets coded. |
80 |
|
81 |
-- |
82 |
Duncan - List replies preferred. No HTML msgs. |
83 |
"Every nonfree program has a lord, a master -- |
84 |
and if you use the program, he is your master." Richard Stallman |