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