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 1DDA413888F for ; Sun, 18 Oct 2015 08:47:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CB23921C04E; Sun, 18 Oct 2015 08:47:09 +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 DFED321C014 for ; Sun, 18 Oct 2015 08:47:08 +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 90A7033BF0B for ; Sun, 18 Oct 2015 08:47:06 +0000 (UTC) Date: Sun, 18 Oct 2015 10:47:01 +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: <20151018104701.3b0acf46@gentoo.org> In-Reply-To: <20151017232447.3f42d43a.mgorny@gentoo.org> References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <20151017220838.0ae4973f@gentoo.org> <20151017232447.3f42d43a.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: 6e0d078b-3241-4438-9fdf-a4604a4ca770 X-Archives-Hash: 56ebbecfd14b0d78e3f834f0e789cd78 On Sat, 17 Oct 2015 23:24:47 +0200 Micha=C5=82 G=C3=B3rny wrote: > On Sat, 17 Oct 2015 22:08:38 +0200 > Alexis Ballier wrote: >=20 > > On Fri, 16 Oct 2015 20:42:20 +0200 > > Ulrich Mueller wrote: > > =20 > > > [Resending since my first message didn't make it to > > > -dev-announce.] > > >=20 > > > 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. > > >=20 > > > Please review. The goal is to have the draft ready for approval > > > in the council's November meeting. =20 > >=20 > > 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 ? =20 >=20 > How many decades, exactly? ;-) from 1.5 to 1.6 I'd say :p [...] > > 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. =20 >=20 > The poor man's autodetection implemented in epatch was... well, poor. > It had its corner cases when it failed hard, it was complex and made > error handling PITA (which patch invocation really failed?!). There's a log for understanding which invocation failed. > It's trivial to change patch to -p1 (I think patchutils can do that). It is. But the above cases were not whether it is possible, but rather desirable. > It's beneficial to keep patches with predictable directory structure. > And after all, you can use 'eapply -pN' explicitly. And yes, I know > you hate having to think instead of having some random hidden > implicit, likely-to-fail logic do it for you. Well, there's that, but I also wonder why every single ebuild uses epatch and not 'patch -p1 < ...' directly if epatch is so bad... But my point was not there: I still fail to understand why we should set in stone something not so well tested in comparison to epatch, that doesn't seem to provide any gain besides a default phase that an eclass can also provide, that has less features and that can't be changed/fixed easily. Alexis.