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. 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. 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. However, IMO we should be trying to move away from these kinds of eclasses (other than the two cases above). It is really pretty to just type inherit foo at the top of your ebuild and watch the magic happen, until it isn't. As has already been pointed out, if we allow eapply_user to be called anything other than exactly once, then you run into various situations where it ends up not being called correctly. And we can hardly make it a NOOP every time but the last time unless we do two-pass src_prepare or solve the halting problem, neither of which is appealing. -- Rich
