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