(To avoid repeating the same exception over and over, please understand that nothing said below is intended to apply to the do-everything eclasses used by KDE/etc, where the eclass and ebuilds are carefully maintained in conjunction with each other.)
On Mon, Oct 19, 2015 at 9:34 AM, Alexis Ballier <[email protected]> wrote: > > However, by somewhat throwing away the problem, you're just asking for > a complete mess The intent of the next paragraph was to not throw away the problem. > >> 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. That means that anybody creating an ebuild that uses an eclass which does export src_prepare should define the phase in the ebuild, call the various eclass src_prepares in the appropriate orders, and call eapply_user in the appropriate place. Since the ebuild needs to be modified to use EAPI6 it can be done at that time. > Going through each eclass exporting src_prepare and defining > which should export it and which should not. I hope what you say is > sufficient, but it'd be a bad idea to set this in stone for realizing > in a few months that this forces people to write crappy code for having > some eclasses to co-exist nicely. You already need to write crappy code to get some eclasses to co-exist nicely, because they export conflicting phase functions assuming they're the only eclass you'll use. The eclass docs already indicate which ones export src_prepare. If you're using one of those you need to make sure you're overriding it, and calling eapply_user. As long as eclasses don't call eapply_user we're fine. > > Some temptative list of which could be annoying (as in, do not seem to > be 'do everything' eclasses): > > bzr.eclass > -> patches (now useless) and bootstrap script, dropping it might > encounter some resistance > cuda.eclass > -> appends cflags, could easily be moved to src_configure and not > exported > java-pkg-opt-2.eclass > -> sanity checks & autofixing, not sure how to handle > subversion.eclass > -> patches (now useless) and bootstrap script, dropping it might > encounter some resistance > vala.eclass > -> sets up some kind of virtual env, could very well be src_configure The solution to these kinds of problems isn't to remove functionality from the eclass, but rather just export a function that ebuilds can call from src_prepare at the appropriate time, rather than just trying to do it all magically. This was discussed fairly extensively at: http://article.gmane.org/gmane.linux.gentoo.devel/92581 I'm not attempting to tackle that now, but as a step in the right direction I suggest that eclasses not try to call eapply_user in general, and then we don't have to worry about the situation where you want to use three eclasses which all try to call it. I think the long-term solution is to stop exporting phase functions in eclasses. I'd recommend stripping the ability to do so at all from PMS, except for the whole KDE exception which makes sense to me. -- Rich
