From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 54A9A13888F for ; Mon, 19 Oct 2015 13:35:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EE2FF21C04E; Mon, 19 Oct 2015 13:35:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E7E2F21C018 for ; Mon, 19 Oct 2015 13:35:04 +0000 (UTC) Received: from localhost (AMontpellier-655-1-282-73.w81-251.abo.wanadoo.fr [81.251.34.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 8B5173407A3 for ; Mon, 19 Oct 2015 13:35:01 +0000 (UTC) Date: Mon, 19 Oct 2015 15:34:47 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review Message-ID: <20151019153447.7d4ea655@gentoo.org> In-Reply-To: References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <20151017142418.006bc430.mgorny@gentoo.org> <56223EEE.1070903@gentoo.org> <22050.17536.189338.594956@a1i15.kph.uni-mainz.de> <22051.27744.10750.915665@a1i15.kph.uni-mainz.de> <20151018121311.736f703c.mgorny@gentoo.org> <22051.29142.931683.738922@a1i15.kph.uni-mainz.de> <20151019091243.02aed0d4@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 9c5b460e-dd26-4678-841a-157fd077706f X-Archives-Hash: ab47af7ae32660973dc017fd19f4188d On Mon, 19 Oct 2015 08:38:49 -0400 Rich Freeman wrote: > On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier > 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 [...]