On Mon, 19 Oct 2015 13:17:13 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier > <aball...@gentoo.org> wrote: > > On Mon, 19 Oct 2015 09:51:20 -0400 > > Rich Freeman <ri...@gentoo.org> 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. ok, or the eclass can change api with eapi6 which is quite common, and preferably *before* any eapi6 ebuild uses it again, history doesn't have to repeat itself, but it has shown that if eclasses aren't updated properly quickly, it'd be a mess > > > > 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. That's what I feared... I would definitely put it in cmake-utils, since the idea behind all those *-utils.eclass is that they're fed with options and do all the grunt work for you. Think of them as default phases for a given build system. What you propose is close to having eapply_user mandatory in eapi6 but having default src_prepare not calling it... Following your criteria, the list I provided is very far from complete, and should include all the *-utils eclass, multilib ones, and probably many others I don't even dare to look for. However, as you say, putting it in cmake-utils needs to be properly thought so that it doesn't conflict with other eclasses: Hence the need to properly define what eclasses should call eapply_user and apply patches and what should not. Your initial argument was very convincing, but under those conditions, it seems way much saner to make eapply_user idempotent and be done. (and maybe in addition require informally that eapply_user is called after applying patches, but that'd fall under good practices rather than rules)
