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-50219-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S71NF-0006SD-UK
for garchives@archives.gentoo.org; Mon, 12 Mar 2012 09:17:02 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 40268E0BA5;
Mon, 12 Mar 2012 09:16:48 +0000 (UTC)
Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com [209.85.215.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 4EE13E0B5A
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Mar 2012 09:16:13 +0000 (UTC)
Received: by lahc1 with SMTP id c1so3732660lah.40
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Mar 2012 02:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=WfON5JB1lycARY1p0lx0kln/BsRxJV4zJtAvBhH19qU=;
b=Ie1uQseeJ5sKK1gJEWrEAAB2MuGUPrWNgztd22EZQVWfeVQAEM3zQefkXyfaKMzbYr
BmiizxPdVj5dE8vfot3/SUzRZ5IDl1Ergn4dV1G4UgK1Lol5bDfkyQ/nj9TJAYTxMf7u
ty2TYbBSDqKE2ox1fEw0SqRiPg0od+G9NwDCWB3RoRIRMXlEQ1J6jJZRErlPQf+3Unqi
EeAuUsNkcS22EBqHATD6/m95UR9Cpci53tE+efO99FRpkzlHqNV47QCaIIMQqWR3Ol/C
PScACvzd9OQSQcVvE1OfVepBZ7CiWWkfIJrbC5H+87cG55QsMQFb27Q4FffRoxTjT1FB
bOEQ==
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.112.48.130 with SMTP id l2mr4421789lbn.41.1331543772318; Mon,
12 Mar 2012 02:16:12 -0700 (PDT)
Received: by 10.112.102.195 with HTTP; Mon, 12 Mar 2012 02:16:11 -0700 (PDT)
In-Reply-To: <20120312100904.55b1a577@pomiocik.lan>
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>
Date: Mon, 12 Mar 2012 22:16:11 +1300
Message-ID: <CAATnKFAHb4gkC-earRhtUn9YKr8NaO69h_Vfnp4qy638t_BemA@mail.gmail.com>
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 50966943-7013-484a-adc7-ef9c218cd4db
X-Archives-Hash: e0648e2c5535a6695d1e7b8102614c40
On 12 March 2012 22:09, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
>> or as <eapi value=3D"15" />.
>
> No, definitely not. That's not the XML style.
Sure, but these examples are just examples after all. And XML is only
being used for an example use case, but there are many more
structured formats than XML.
Some of us are mostly just worried that the proposals as they stand
won't be resilient enough to allow a future that isn't bash.
>> Part of the point of all of this is that we shouldn't have to guess
>> what future EAPIs will look like.
>
> I'm just suggesting a way which will support a little more than
> bash-based solutions. We could also assume that if a file doesn't match
> the regexp at all, it's a unsupported EAPI.
I just find a top-down regexp solution dangerously naive, as its
infering that the first line that matches the regexp *is* the EAPI
requirement field, when depending on the actual format used, that may
not be the case.
If for example, a format is machine generated, and the EAPI
declaration accidentally comes after something that *isnt* an EAPI
declaration but by the regexp, LOOKS like one, then the probing
mechanism will resolve the WRONG value.
And that doesn't strike me as being very resilient.
--=20
Kent
perl -e=C2=A0 "print substr( \"edrgmaM=C2=A0 SPA NOcomil.ic\\@tfrken\", \$_=
* 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"