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 1E9B513888F for ; Sat, 17 Oct 2015 20:08:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2AD7A21C035; Sat, 17 Oct 2015 20:08:47 +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 17ABB21C018 for ; Sat, 17 Oct 2015 20:08:45 +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 55F1E340754; Sat, 17 Oct 2015 20:08:43 +0000 (UTC) Date: Sat, 17 Oct 2015 22:08:38 +0200 From: Alexis Ballier To: Ulrich Mueller Cc: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review Message-ID: <20151017220838.0ae4973f@gentoo.org> In-Reply-To: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> 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: 15f84eeb-7cd1-4fc0-ac8a-388440537725 X-Archives-Hash: 039e1471c32fa2ba6c8be06f480cc723 On Fri, 16 Oct 2015 20:42:20 +0200 Ulrich Mueller wrote: > [Resending since my first message didn't make it to -dev-announce.] > > The first draft of EAPI 6 is ready. I shall post it as a series of > 22 patches following this message in the gentoo-pms mailing list. > > Please review. The goal is to have the draft ready for approval in the > council's November meeting. Sorry for coming very late on this, but what is the rationale behind setting in stone an 'eapply' different to an 'epatch' that has been widely tested for decades now ? Or even defining eapply in PMS ? I can understand "eapply is a function that applies patches" isn't nice for a spec., but we've already seen in the past gnu patch changing behavior wrt what is an acceptable patch between versions, bsd 'patch' command behaves slightly differently than gnu patch (read: is unusable with epatch), etc. One can argue that gnu patch changing behavior is part of life, but what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch, 'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch for ebuilds, but I don't think profile.bashrc should mess up with what is mandated by PMS. Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts -p0 patches by default here. Or when $S is actually a subdir of a repository, this will make standard git format-patch generated patches unusable. Alexis.