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 BE16C13888F for ; Mon, 19 Oct 2015 18:28:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AA5D2E0804; Mon, 19 Oct 2015 18:28:29 +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 98BF3E07E0 for ; Mon, 19 Oct 2015 18:28:28 +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 BD40C340662 for ; Mon, 19 Oct 2015 18:28:24 +0000 (UTC) Date: Mon, 19 Oct 2015 20:28:16 +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: <20151019202816.694b344f@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> <20151019153447.7d4ea655@gentoo.org> <20151019162125.1618c432@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: d630dd52-4d4f-451c-b79d-2f6a2cb71921 X-Archives-Hash: 3ca1a351f3aaaa8c30ada9e1341aec02 On Mon, 19 Oct 2015 13:17:13 -0400 Rich Freeman wrote: > On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier > wrote: > > On Mon, 19 Oct 2015 09:51:20 -0400 > > Rich Freeman 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)