| 1 |
> Right now we have support in some packages for user patches - those being |
| 2 |
> patches dropped into /etc/portage/patches/pkgname/ - which are |
| 3 |
> automatically applied. Because this feature is implemented by |
| 4 |
> epatch_user() in |
| 5 |
> eutils.eclass, it is only available for ebuilds that inherit eutils and |
| 6 |
> explicitly call epatch_user or inherit another eclass that calls it in an |
| 7 |
> exported phase (eg. base). The end result is a very inconsistent |
| 8 |
> experience, where user patches may or may not work not only on a |
| 9 |
> package-by-package basis, but ebuild-by-ebuild. |
| 10 |
> |
| 11 |
> Is there any reason why this couldn't just be done in the package manager, |
| 12 |
> making user patches available for all ebuilds without code changes? |
| 13 |
|
| 14 |
Well as people have already pointed out, the problem is where to place it: |
| 15 |
* before src_prepare is bad because of gentoo-patches |
| 16 |
* after src_prepare is bad because of eautoreconf calls in src_prepare |
| 17 |
|
| 18 |
I would even suggest a more radical approach, namely (for an upcoming EAPI) to |
| 19 |
migrate some of the features of base.eclass into the package manager. Applying |
| 20 |
patches is a universal problem which should be handled as central as possible. |
| 21 |
|
| 22 |
As example, (in that future EAPI) |
| 23 |
* have patches from the PATCHES array be applied automatically _before_ |
| 24 |
src_prepare (the same way as done currently in base_src_prepare) |
| 25 |
* have user patches applied afterwards (either if a FEATURE is set, or |
| 26 |
generally) |
| 27 |
* disallow or deprecate at least direct calls to epatch, to ensure ordering |
| 28 |
* (and adapt the functions in base and eutils accordingly for that EAPI) |
| 29 |
|
| 30 |
Opinions? |
| 31 |
|
| 32 |
Best, Andreas |
| 33 |
|
| 34 |
-- |
| 35 |
|
| 36 |
Andreas K. Huettel |
| 37 |
Gentoo Linux developer |
| 38 |
dilfridge@g.o |
| 39 |
http://www.akhuettel.de/ |
Archives