Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/26/2012 03:08 PM, Duncan wrote:
> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
>> 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.

Having the package manager interact with an eclass function like 
epatch_user is ugly, and it's unnecessary since we can pull all of the 
pieces into the package manager in EAPI 5. Any eclasses that currently 
call epatch_user can have a conditional like this:

   if has $EAPI 0 1 2 3 4 ; then
     epatch_user
   else
     apply_user_patches_here
   fi

>> 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.

I think it might be better to die if it's not called in src_prepare, 
like Ciaran originally suggested. This ensures that people don't forget 
to call it when they are supposed to.

> 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.

It's no worse than epatch_user currently is. It's the responsibility of 
the person who overrides src_prepare to call eautoreconf or whatever 
else when necessary, so the package manager will not have the burden.
-- 
Thanks,
Zac