> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico <zmedico@...> 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 ....