On 2012-04-15, at 5:03 AM, Ryan Hill <dirtye...@gentoo.org> wrote:
> On Sun, 15 Apr 2012 01:35:40 -0700 > Zac Medico <zmed...@gentoo.org> 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 ....
