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 2FE8613888F for ; Tue, 20 Oct 2015 10:25:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20ECC21C031; Tue, 20 Oct 2015 10:25:17 +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 26DEC21C011 for ; Tue, 20 Oct 2015 10:25:16 +0000 (UTC) Received: from localhost (AMontpellier-655-1-366-77.w90-28.abo.wanadoo.fr [90.28.198.77]) (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 6E93133D3CD for ; Tue, 20 Oct 2015 10:25:13 +0000 (UTC) Date: Tue, 20 Oct 2015 12:25:07 +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: <20151020122507.5cbcac85@gentoo.org> In-Reply-To: References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <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> <20151019202816.694b344f@gentoo.org> <20151020095154.011d4265@gentoo.org> <20151020112227.1b7df84b@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: 30139ffd-8f3c-48f9-b5fd-665ac6ff1d13 X-Archives-Hash: c63a9b0cd5aaa5cb2d81c451bb37a60f On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman wrote: [...] > > > > First, eclasses shouldn't apply patches on their own but take what > > the ebuild tells it to apply: With multiple eclasses applying random > > patches on their own, you're already asking for trouble. > > Then, ebuild can just send all its patches through the first eclass, > > which will call the real eaplly_user. > > > > Sure, there can be imaginary cases where this would horribly break > > or not be so convenient, but do we have a real example ? > > That is a fair point. I think there are other problems with eclasses > exporting phase functions which are far more likely to cause issues > than patching at the wrong spot. Probably, indeed. > I guess the question is whether I/we/whoever is turning eapply_user > into a big issue more to force the general move away from exporting > phase functions than because it is a big issue on its own. I do think > that is the direction we ought to be moving in, but I would agree that > we shouldn't be using eapply_user as a club to try to force people to > move that way. If we want to discourage eclass phase function > exporting, we should just do that on its own merits. Heh, going OT, I guess I'd be on the other side: kill the autotools-centric default phases and move everything to eclasses' exported functions :) (or make default phases much more friendly to non-autotools build systems, but that'd likely double pms size with useless considerations) > So, perhaps it is a fair question to ask what is the specific harm > from allowing it to be a no-op on subsequent calls, other than > encouraging a coding practice that could possibly have other unrelated > effects? Yep; I can't see any real harm, but this is probably based on a limited view of the big picture. However, I do think the practice should be discouraged, but 'let be' in specific cases like for eclasses co-existence. Actually, just like any other (non breaking) QA issue is handled I think.