On Mon, 19 Oct 2015 08:38:49 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier <aball...@gentoo.org> > wrote: > > But there is something important we've overlooked: should eclasses > > that export src_prepare call eapply_user ? I think yes, otherwise > > they'd make packages inheriting them violate the 'at least once > > rule'. > > This sort of thing has been discussed by the council, though we didn't > make a specific recommendation on the eclass authoring side. The > exactly once language was specifically chosen to force eclass/ebuild > authors to consider this problem, because bad things happen if you > don't. > > I'd argue that eclasses should fall into two categories: > 1. Utility eclasses. These are things like git.eclass that export > useful functions that ebuilds can call. They shouldn't export phase > functions, so ebuild authors can use as many of these as they want and > they'll never conflict. > 2. Do-everything eclasses. These are things like the kde eclasses > which operate with the design that the packages themselves do almost > nothing, and all the work is in the eclass. It allows things like > splitting up kde ebuilds without having a ton of duplicated code in > hundreds of packages. These should export phase functions, and you > tend to run into all kinds of problems if you try to use more than one > of them, so you shouldn't. > > So, if you're writing a utility eclass you shouldn't be exporting > src_prepare, and so you're fine. By all means export a function > designed to be called during src_prepare, but don't export the phase > itself. yes, exactly, but... > If you're writing a do-everything eclass then do whatever makes the > most sense. Most likely you're co-maintianing every package that uses > the eclass anyway. Just document how you're doing it. > > The real problem is when people try to do something in-between, which > happens with a lot of language-based eclasses it seems. Then when you > have some package that uses three different languages in its build > system you get to deal with a mess of which eclass should be doing > what. We really need to get away from this. vcs eclasses maybe ? some of them export src_prepare, though they could probably drop it for eapi6 However, by somewhat throwing away the problem, you're just asking for a complete mess :) some will invent variables to notify eclass has called eapply user, some will just not call it by requiring consumers to define its src_prepare (killing the point of EXPORT_FUNCTIONS), or what else I can't imagine. I still remember eapi2 transition with numerous packages calling econf twice :) > 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: 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. 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 [...]
