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 ) id 1S77l4-0002Mm-Hl for garchives@archives.gentoo.org; Mon, 12 Mar 2012 16:06:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E42EFE093E; Mon, 12 Mar 2012 16:05:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id BD2B5E0961 for ; Mon, 12 Mar 2012 16:05:28 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 41D921B400A for ; Mon, 12 Mar 2012 16:05:28 +0000 (UTC) Message-ID: <4F5E1EC6.3050508@gentoo.org> Date: Mon, 12 Mar 2012 09:05:26 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120304 Thunderbird/10.0.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds References: <4F5A1C46.7080005@gentoo.org> <4F5A2001.30309@orlitzky.com> <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> In-Reply-To: <20120312083612.GF7579@localhost> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: b34c3a51-c03c-474d-89e9-c963cc6d05cf X-Archives-Hash: cab8d1464727fa10f0ea33f3c60176bd 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. > 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, 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. > 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. -- Thanks, Zac