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 2108B13888F for ; Mon, 19 Oct 2015 08:17:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3EF9B21C030; Mon, 19 Oct 2015 08:17:16 +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 3CF68E07F5 for ; Mon, 19 Oct 2015 08:17:15 +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 B4178340566 for ; Mon, 19 Oct 2015 08:17:13 +0000 (UTC) Date: Mon, 19 Oct 2015 10:17:08 +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: <20151019101708.7ad20139@gentoo.org> In-Reply-To: <20151019100941.2243de74.mgorny@gentoo.org> 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> <20151019095834.22f15567.mgorny@gentoo.org> <20151019100422.6937832f@gentoo.org> <20151019100941.2243de74.mgorny@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f9d41bfb-50b0-44ce-8fbd-8cffc83c9d91 X-Archives-Hash: 9485d1328add8ac54356d0146628f7a0 On Mon, 19 Oct 2015 10:09:41 +0200 Micha=C5=82 G=C3=B3rny wrote: > On Mon, 19 Oct 2015 10:04:22 +0200 > Alexis Ballier wrote: >=20 > > On Mon, 19 Oct 2015 09:58:34 +0200 > > Micha=C5=82 G=C3=B3rny wrote: > > =20 > > > On Mon, 19 Oct 2015 09:12:43 +0200 > > > Alexis Ballier wrote: > > > =20 > > > > On Sun, 18 Oct 2015 12:17:58 +0200 > > > > Ulrich Mueller wrote: > > > > =20 > > > > > >>>>> On Sun, 18 Oct 2015, Micha=C5=82 G=C3=B3rny wrote: = =20 > > > > > =20 > > > > > > On Sun, 18 Oct 2015 11:54:40 +0200 > > > > > > Ulrich Mueller wrote: =20 > > > > > =20 > > > > > >> So the question is if we should add a sentence like the > > > > > >> following to the spec: > > > > > >>=20 > > > > > >> In EAPIs where it is supported, all ebuilds must run > > > > > >> \t{eapply\_user} in the \t{src\_prepare} phase. =20 > > > > > =20 > > > > > > How about: =20 > > > > > =20 > > > > > > In EAPIs listed in table blah blah blah, > > > > > > \t{eapply\_user} must be called exactly once in the > > > > > > \t{src\_prepare} phase. =20 > > > > > =20 > > > > > > Which emphasizes that eclass or default may do it instead of > > > > > > ebuild. =20 > > > > >=20 > > > > > Yeah, that's better actually. We need not reference the table > > > > > again though, since we do it in the sentence before. > > > > >=20 > > > > > In EAPIs where it is supported, \t{eapply\_user} must be > > > > > called exactly once in the \t{src\_prepare} phase. =20 > > > >=20 > > > >=20 > > > > +1 > > > >=20 > > > > 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'. =20 > > >=20 > > > Why do you assume I overlooked something? =20 > >=20 > > you're not the center of the world m'dear :) > > =20 > > > I thought exactly of this > > > case, and decide that will force developers to finally write sane > > > eclasses. =20 > >=20 > > then, care to share how, o great mgorny? =20 >=20 > Like not redefining src_prepare() all the time. Hmm, or maybe I was > wrong and it won't be this easy ;-P. But that's probably a problem to > be solved on eclass level, not PMS level. maybe, maybe not so far we have one, unperfect, solution for the pms level; i find the 'exactly once' rule nice & clear, but i cannot get my mind on how it can be done at eclass level...