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-50351-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S7dXT-00054I-2Y
for garchives@archives.gentoo.org; Wed, 14 Mar 2012 02:02:07 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id F3063E0B74;
Wed, 14 Mar 2012 02:01:57 +0000 (UTC)
Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 2B1DBE0B18
for <gentoo-dev@lists.gentoo.org>; Wed, 14 Mar 2012 02:01:31 +0000 (UTC)
Received: by iaoo28 with SMTP id o28so2039593iao.40
for <gentoo-dev@lists.gentoo.org>; Tue, 13 Mar 2012 19:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=4CmGagm9YoW/uapRZ1p4t27XdwkYf/t1yRCaXTCHiGA=;
b=uWcGDfG+2PEcdGz1oLPrLWZ4gVIXetTJCCdwIR30XtxK2XJzZwReDfdPq7LuXIoijC
wl5s27OjibnIYvAB9rKlFdjYYJZZnEfN3MFMYupkMuils3Rdb5YcbiMeRY0RpNhfmCwH
ltc/yYQ/VDjLMqf6YbWDo8sKdUFMo0XOqij1LT4mcBRIvSqKvxpzie46C9oF8dZiUvN7
i2fQcvnbJNxDgJYNeTVrBf0F8gJNLfH/xlC/G8Pj4OR5rqjhTVrf2hnjeuauDUQj/RAX
HUDL4OElyHjHfMJKFX1EbFZ2WurDy37fVW4gOOQ6YGtQbtTQBrOYIE7vWGWpwZNXfOBy
qwtA==
Received: by 10.50.184.228 with SMTP id ex4mr1178263igc.50.1331690491748;
Tue, 13 Mar 2012 19:01:31 -0700 (PDT)
Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101])
by mx.google.com with ESMTPS id wf10sm2334578igb.8.2012.03.13.19.01.27
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 13 Mar 2012 19:01:30 -0700 (PDT)
Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 13 Mar 2012 19:01:27 -0700
Date: Tue, 13 Mar 2012 19:01:27 -0700
From: Brian Harring <ferringb@gmail.com>
To: Zac Medico <zmedico@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
Message-ID: <20120314020127.GB7731@localhost>
References: <4F5A2495.4060305@gentoo.org>
<20120309125126.186969f9@gentoo.org>
<4F5A28B6.2010404@gentoo.org>
<4F5A34A8.4080200@orlitzky.com>
<20120309192054.776bcd56@googlemail.com>
<4F5B7C1A.6060509@gentoo.org>
<20120312015533.GD7579@localhost>
<4F5D76B8.5040102@gentoo.org>
<20120312083612.GF7579@localhost>
<4F5E1EC6.3050508@gentoo.org>
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
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F5E1EC6.3050508@gentoo.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: f1063fb9-36ed-47b9-a457-66629c8424ab
X-Archives-Hash: 5557feef583c992755dd5f7374fdd3da
On Mon, Mar 12, 2012 at 09:05:26AM -0700, Zac Medico wrote:
> On 03/12/2012 01:36 AM, Brian Harring wrote:
> > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
> >> 1) User downloads an overlay that doesn't provide cache. We want the
> >> package manager to give a pretty "EAPI unsupported" message, rather than
> >> spit out some bash syntax errors.
> >
> > This criticsm pretty much applies *strictly to the existing
> > implementation*. It's disenguous busting it in this fashion.
> >
> > EAPI as a function explicitly gives it an out before hitting any of
> > that, eliminating your entire critique. Same goes for parsing it out
> > of the ebuild, or renaming the extension.
>
> You're assuming that the ebuild calls your eapi() function before it
> uses any syntax that's unsupported by the user's installed version of bash.
A bit, although that's a pretty valid assumption frankly. For current
bash syntax, the only thing they could do that would cause issues is
bash regex's for example- which if they have regex's prior to the eapi
invocation, they're doing something stupid anyways.
Regardless, detecting and suppressing isn't too hard- start sourcing
w/ `set -e`, disabling that once `eapi` has been invoked for example.
Pretty sure people will scream "that's horrible", but it's
surprisingly effective.
> > 1) PM still doesn't support that EAPI, looks at the cache/ebuild:
> > checksums are the same, thus the stored EAPI is trustable, leading to
> > the PM knowing it still can't process that ebuild and masking it
> > appropriately.
>
> You're assuming that cache is provided by the repo,
Sigh. I'm making no such assumptions, nor would I; it's a stupid line
of thought.
All of this has to function in the absence of a cache, and that's a
core usage scenario.
> which is not
> guaranteed, depending on the source. Even if the cache does exist, then
> you're assuming it's in a format that the package manager can reliably
> parse the EAPI from, even though that EAPI may not be supported. That
> may or may not reliable assumption, and having a pre-defined protocol to
> directly obtain the EAPI without using the cache is much more reliable.
This is a nonstatement. To deal w/ the cache (validate it) you have
to be able to reliably pull EAPI out of the ebuild.
That's what this whole fucking discussion is about; really not sure
why you're trying to argue this point against eapi as a function. As
I already laid out, it can deal w/it, same as the rest. Importantly,
the approach can also work across the transition period preventing
current-day PMs (using current EAPI mechanisms) from breaking when
used against later EAPIs that were released via `eapi as a function`.
> > What I'd like to see, is accuracy in this discussion. Skip the
> > handwavey "complexity! complexity! complexity!" crap, same for
> > selective robustness definitions. Past attempts at this discussion
> > mostly failed due to people pulling crap like this and frankly it just
> > pisses people off.
>
> It's just a symptom of people not abiding by the KISS principle. When
> you start talking about an approach such as the "eapi() function"
> approach which introduces lots of unnecessary complexity, it naturally
> makes the whole discussion more complex and hand-wavey.
With respect; you're proposing we go gum up version parsing via
shoving EAPI directly into it. Literally, make what is already a
complex mess, worse. Apply some KISS to your proposal please. ;)
Just hammering the point home; compatibility *is* complex. Claiming
otherwise is naive. Case in point: your proposal breaks the shit out
of any current-day package manager that saw such a filename.
I really have a hard time reading your posts when basic issues like
that aren't paid attention to, but you've no problems claiming
complexity/brokenness in other proposals.
As I said, I'd like to see some accuracy; not hand wavy buzzwords.
I'd much more like to see prototypes of peoples proposals in addition
since at least that way they would flush out the breakages in their
proposals (potentially dropping it in the process since some of these
are pretty half baked).
~brian