Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: "gentoo-dev@l.g.o" <gentoo-dev@l.g.o>
Cc: "gentoo-dev@l.g.o" <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Re: Making user patches globally available
Date: Sun, 15 Apr 2012 13:47:48
Message-Id: EE0C2560-CB73-45B9-A377-1F8D27949B09@gentoo.org
In Reply to: [gentoo-dev] Re: Making user patches globally available by Ryan Hill
1 On 2012-04-15, at 5:03 AM, Ryan Hill <dirtyepic@g.o> wrote:
2
3 > On Sun, 15 Apr 2012 01:35:40 -0700
4 > Zac Medico <zmedico@g.o> wrote:
5 >
6 >> On 04/15/2012 01:16 AM, Ryan Hill wrote:
7 >>> Right now we have support in some packages for user patches - those being
8 >>> patches dropped into /etc/portage/patches/pkgname/ - which are automatically
9 >>> applied. Because this feature is implemented by epatch_user() in
10 >>> eutils.eclass, it is only available for ebuilds that inherit eutils and
11 >>> explicitly call epatch_user or inherit another eclass that calls it in an
12 >>> exported phase (eg. base). The end result is a very inconsistent experience,
13 >>> where user patches may or may not work not only on a package-by-package
14 >>> basis, but ebuild-by-ebuild.
15 >>>
16 >>> Is there any reason why this couldn't just be done in the package manager,
17 >>> making user patches available for all ebuilds without code changes?
18 >>
19 >> Funtoo has support for FEATURES=localpatch, which does the epatch_user
20 >> thing before src_prepare. I think it should really go after src_prepare,
21 >> in order to apply patches after those that src_prepare may apply
22 >> (avoiding possible conflicts).
23 >
24 > I agree.
25 >
26 >> The reason that Funtoo's FEATURES=localpatch applies patches before
27 >> src_prepare is that it's common for eautoreconf to be called inside
28 >> src_prepare, and applying patches after src_prepare can create a need to
29 >> call eautoreconf a second time.
30 >
31 > Well that could waste a bit of time but is pretty much harmless, no? And the
32 > existing usages of epatch_user (other than autotools-utils) don't eautoreconf
33 > anyways, nor should they in case the package doesn't use autotools.
34 >
35 >
36
37
38 the existing use of epatch_user allow you to put the call after current epatchez and before the eautoreconf call..
39
40 I agree tho -- an automatic call to eautoreconf could be triggered by features=localpatch whenever there are patches and autotools.eclass is inherited.
41
42 also, any user patches applied could be cat'd to the build log, to allow for debugging ....