1 |
On Sun, 15 Apr 2012 02:16:41 -0600 |
2 |
Ryan Hill <dirtyepic@g.o> wrote: |
3 |
|
4 |
> Right now we have support in some packages for user patches - those |
5 |
> being patches dropped into /etc/portage/patches/pkgname/ - which are |
6 |
> automatically applied. Because this feature is implemented by |
7 |
> epatch_user() in eutils.eclass, it is only available for ebuilds that |
8 |
> inherit eutils and explicitly call epatch_user or inherit another |
9 |
> eclass that calls it in an exported phase (eg. base). The end result |
10 |
> is a very inconsistent experience, where user patches may or may not |
11 |
> work not only on a package-by-package basis, but ebuild-by-ebuild. |
12 |
|
13 |
That's why we should work on spreading the use of base eclass or one of |
14 |
similar eclasses rather than reinventing the wheel. On the other hand, |
15 |
taking into consideration that base.eclass is a pretty roughly shaped |
16 |
wheel we could consider creating a new base eclass for that. |
17 |
|
18 |
> Is there any reason why this couldn't just be done in the package |
19 |
> manager, making user patches available for all ebuilds without code |
20 |
> changes? |
21 |
|
22 |
It should have been done there in the first place. But it hasn't, |
23 |
and this has some advantages. For example, thanks to complete control |
24 |
over the moment where epatch_user() is called, autotools-utils is able |
25 |
to smartly do autoreconf when needed. If user patches were forced to be |
26 |
PM-only feature, there would be no good way of doing that. |
27 |
|
28 |
-- |
29 |
Best regards, |
30 |
Michał Górny |