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 25F1E13888F for ; Sun, 18 Oct 2015 19:20:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A048521C046; Sun, 18 Oct 2015 19:20:36 +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 8A6DB21C030 for ; Sun, 18 Oct 2015 19:20:35 +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 02AC5340634 for ; Sun, 18 Oct 2015 19:20:33 +0000 (UTC) Date: Sun, 18 Oct 2015 21:20:28 +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: <20151018212028.1288fbe4@gentoo.org> In-Reply-To: <20151018193609.4eb4e1d2@googlemail.com> References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <20151017220838.0ae4973f@gentoo.org> <22050.46048.380633.7007@a1i15.kph.uni-mainz.de> <20151018103109.2ecfc0db@gentoo.org> <20151018134430.3867455d@googlemail.com> <20151018200011.3e4bd541@gentoo.org> <20151018190633.77a52a53@googlemail.com> <20151018201912.04f98f6a@gentoo.org> <20151018193609.4eb4e1d2@googlemail.com> 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: b3bea184-95c7-4804-a206-bb7511ca9030 X-Archives-Hash: ff4b7edfaf56541eafbfae23f357f99d On Sun, 18 Oct 2015 19:36:09 +0100 Ciaran McCreesh wrote: > On Sun, 18 Oct 2015 20:19:12 +0200 > Alexis Ballier wrote: > > what I was trying to understand is what is the usefulness of eapply > > vs epatch > > The point of eapply is that it's inside the package manager, so it can > safely be used by default phase functions, for user patches, etc. For user patches, I agree, but it can be very loosely defined and left implementation dependent instead of mandated by PMS. For default phases, see below. > Rather than it being a direct copy of the epatch API, we took this as > an opportunity to tidy up the behaviour to make it do something easy > to understand and sensible, rather than being full of scary voodoo > heuristics which are rarely necessary (and when they are, fixing your > patches is easy) and which have weird effects that you don't know > about until it's too late. Makes sense, but it equally applies to 'patch', or worse: I've seen many patches working with some 'patch' version and being rejected by other versions. I've never seen anything like that caused by epatch itself. > Of course, this is part of the larger debate on "as much as possible > in the PM" versus "as much as possible in the tree". The main "in the > PM" argument is "less breakage and better testing"; the main "in the > tree" argument is that things going spectacularly wrong for users > every now and again is fine because it lets developers have new > useless toys slightly faster. (This is a totally unbiased and > entirely comprehensive summary of the debate.) clearly unbiased :) The main "in the PM" argument is "everything must be discussed until it is perfect, and if it happens not to be later on then start again the process and it'll be fixed next year"; the main "in the tree" argument is about admitting that no code is perfect nor can do everything we need from its inception but can be fixed and improved easily. There are things that must be properly specified, for which PMS does a very good job at, but others that are just implementation details which IMHO have nothing to do with a spec: default phases could very well be defined by an implicit 'inherit default-phase-functions' applying to all ebuilds and be done with the specification, interoperability problems, etc. You'd tell me we then would have no guarantee that changing something in that eclass wouldn't break an obscure ebuild, which is true, but heh, isn't it the whole point of eclasses ? :) (or rather, this eclass can have very strict pre-commit review & testing rules) [...]