On 2012-04-15, at 5:03 AM, Ryan Hill <dirtyepic@g.o> wrote:

> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico <zmedico@g.o> wrote:
> 
>> On 04/15/2012 01:16 AM, Ryan Hill wrote:
>>> Right now we have support in some packages for user patches - those being
>>> patches dropped into /etc/portage/patches/pkgname/ - which are automatically
>>> applied.  Because this feature is implemented by epatch_user() in
>>> eutils.eclass, it is only available for ebuilds that inherit eutils and
>>> explicitly call epatch_user or inherit another eclass that calls it in an
>>> exported phase (eg. base).  The end result is a very inconsistent experience,
>>> where user patches may or may not work not only on a package-by-package
>>> basis, but ebuild-by-ebuild.
>>> 
>>> Is there any reason why this couldn't just be done in the package manager,
>>> making user patches available for all ebuilds without code changes?
>> 
>> Funtoo has support for FEATURES=localpatch, which does the epatch_user
>> thing before src_prepare. I think it should really go after src_prepare,
>> in order to apply patches after those that src_prepare may apply
>> (avoiding possible conflicts).
> 
> I agree.
> 
>> The reason that Funtoo's FEATURES=localpatch applies patches before
>> src_prepare is that it's common for eautoreconf to be called inside
>> src_prepare, and applying patches after src_prepare can create a need to
>> call eautoreconf a second time.
> 
> Well that could waste a bit of time but is pretty much harmless, no?  And the
> existing usages of epatch_user (other than autotools-utils) don't eautoreconf
> anyways, nor should they in case the package doesn't use autotools.
> 
> 


the existing use of epatch_user allow you to put the call after current epatchez and before the eautoreconf call..   

I agree tho -- an automatic call to eautoreconf could be triggered by features=localpatch whenever there are patches and autotools.eclass is inherited.

also, any user patches applied could be cat'd to the build log, to allow for debugging ....