From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-50270-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S7AoN-0007WV-DL
for garchives@archives.gentoo.org; Mon, 12 Mar 2012 19:21:41 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 86966E0DC9;
Mon, 12 Mar 2012 19:21:15 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 8A4EFE0D1E
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Mar 2012 19:20:15 +0000 (UTC)
Received: by bkwj4 with SMTP id j4so3397565bkw.40
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Mar 2012 12:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=u1KfuwnMNuXWV9KzU/NFUw5Mn7rOJ1ZXj2HzOPQgarE=;
b=XOAK8Jh2kTzb7OI08rKtax0PZDQTsHo+uNehWxebp9cE9EcC4POz2xKP9ZnET3FJeQ
HGUIgow1KH9lpfQxfhGg4B5CrbnCkTr5aXzcfvQb198sYz1WuIuuGczwvZuCW+fiu3gM
3sMm2iHTYzyC0oBLiFqF+weFTzDav5u6B50agAaOyGuZPZpQnz6a0iGEsjwX0fSW1H8U
RSkoizBEotvYbvMCWO+pSAgYq2tLthxIk6d46jNJycxTSmsrDs14XcoVjbbcPANuz5DQ
FUZIqT/vhnYHRo3jszxZonGczudpsJyXbBH/m64yhBg3QTxflF0P/cf2Mn6PFwGJlL+u
GCeg==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.152.27 with SMTP id e27mr5108408bkw.55.1331580014617; Mon,
12 Mar 2012 12:20:14 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.205.32.194 with HTTP; Mon, 12 Mar 2012 12:20:14 -0700 (PDT)
In-Reply-To: <4F5E368C.5070505@gentoo.org>
References: <4F58FC55.7070005@orlitzky.com>
<20120308184820.108fc30c@googlemail.com>
<4F592612.6050203@orlitzky.com>
<20120309060424.09cdce1e@pomiocik.lan>
<4F599692.9050503@orlitzky.com>
<20120309172921.281ee5a0@pomiocik.lan>
<4F5A368D.2020605@orlitzky.com>
<20314.14772.897891.110368@a1i15.kph.uni-mainz.de>
<4F5A3E6C.4040900@orlitzky.com>
<4F5A4246.8080605@gentoo.org>
<20120312020344.GE7579@localhost>
<CAGfcS_=+7E-=zTMLEEFwM8xG4R21AJ3xWaS_HCE8P7PUEtNSyA@mail.gmail.com>
<CAATnKFCy0O5tNtSO_d+2TjFU19shvw-oFmYSAP-mD08HSuR=rw@mail.gmail.com>
<4F5DA0FE.1070405@gentoo.org>
<20120312092711.7dbd969f@pomiocik.lan>
<20120312083019.3d38ffa0@googlemail.com>
<20120312100904.55b1a577@pomiocik.lan>
<CAATnKFAHb4gkC-earRhtUn9YKr8NaO69h_Vfnp4qy638t_BemA@mail.gmail.com>
<4F5E2C02.6030802@gentoo.org>
<CAGfcS_nNntHoDKN-55ecSUOFUijB3QrdzJDwWqL4zQat6DGAFA@mail.gmail.com>
<4F5E368C.5070505@gentoo.org>
Date: Mon, 12 Mar 2012 15:20:14 -0400
X-Google-Sender-Auth: nbcHUQQRFBozUfFzGBa2spjKF5s
Message-ID: <CAGfcS_=KujCExHd5Jc+mTfhAPWmR4uS=uvxc3Bg7-ZNsz4pPVw@mail.gmail.com>
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 8cde032c-925d-4b52-b322-c7d42ccdd490
X-Archives-Hash: dbfc66688a0f9d060c445185375809ab
On Mon, Mar 12, 2012 at 1:46 PM, Zac Medico <zmedico@gentoo.org> wrote:
> If we want to handle every possible screwup, including stray EAPI
> assignments inside inherited eclasses, we still need to compare the
> probed value to the value that's obtained from bash.
Well, I wasn't intending to suggest that the repoman check need be the
only one. However, preventing problems is at least as useful as
detecting them.
That said, it would probably best to have exactly one way to determine
the official EAPI. If that is to parse the filename, then parse the
filename. If it is to grep for a regexp and expect exactly one hit
and parse it in a certain way, then do that.
It might be that the "one" official way is to grep for a regexp and if
you find it, use it, otherwise assume 0, 1, 2, 3, or 4 and source the
ebuild for it. That still gives you only a single answer (well,
except in situations where the current way is already broken).
If people want to abuse the EAPI syntax I suppose we can generate an
error, but ignoring it might be just as valid behavior. I'm not sure
what happens if you define PN/etc in ebuild besides things breaking in
a horrible manner. I'd put changing EAPI in the same category.
Rich