On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier <[email protected]> wrote: > On Mon, 19 Oct 2015 09:51:20 -0400 > Rich Freeman <[email protected]> wrote: > [...] >> > >> >> I'd say the best approach for compatibility if you have an existing >> >> eclass and it already exports src_prepare is to not call >> >> eapply_user unless it firmly falls into the #2 category above. >> > >> > Replace 'not call eapply_user' by 'not export src_prepare' and I'd >> > agree with you if going a bit further by ensuring there is no hidden >> > problem: >> >> Well, taken together my recommendation does amount to: >> 1. Avoid exporting src_prepare at all. >> 2. If you do export src_prepare, then don't call eapply_user. > > 2. sucks: an ebuild inheriting that eclass will have to redefine > src_prepare in order not to break with eapi6, so there's no point in > exporting the function in the first place.
No argument. I'm just saying that nothing stops us from using an existing eclass with EAPI6 without changing function names all over the tree. Non-EAPI6 ebuilds can still use the existing function automatically, and new ebuilds using EAPI6 have to work around the issue until the eclass is revisioned. > > Also, since you seem to know well KDE: where would you call > eapply_user, in kde eclasses or cmake-utils ? > Definitely in a kde eclass. cmake-utils would fall into the category of a utility eclass, so it ideally shouldn't export phase functions at all. Again, I'm not proposing forcing a change on that now, and it needs more thought, but it would be a lousy place to put eapply_user since it could be used in the same ebuild as another eclass that performs a similar function. That might require having the kde eclass call the cmake-utils eclass function. Since the kde eclass is only intended to be used by kde ebuilds maintained by the same group that maintains the eclass, there isn't a problem here. The ebuilds themselves just set a bunch of variables and leave the work to the eclass. -- Rich
