Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Making user patches globally available
Date: Thu, 26 Apr 2012 22:09:39
Message-Id: pan.2012.04.26.22.08.25@cox.net
In Reply to: Re: [gentoo-dev] Re: Making user patches globally available by Zac Medico
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

Replies

Subject Author
Re: [gentoo-dev] Re: Making user patches globally available Zac Medico <zmedico@g.o>