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 1S9TBa-0000fH-Jq for garchives@archives.gentoo.org; Mon, 19 Mar 2012 03:23:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46CC7E0D00; Mon, 19 Mar 2012 03:22:43 +0000 (UTC) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 01A91E0CEE for ; Mon, 19 Mar 2012 03:21:59 +0000 (UTC) Received: by dady25 with SMTP id y25so277575dad.40 for ; Sun, 18 Mar 2012 20:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ov/sWmaPh8QmRr0BcWTPomhFd/dxaM5kgrqFY9JoS2A=; b=HksJUgshkuKPAweJwayEKXjaPKfUnFm8w65z+SV02Wivgp0d5Bjzn/G60VEz5K3zSb ql9XVoiq9YhBbbo5y0PBZQcw1uhKK8jAkz52lF7rBbWvNUL/eUFncR+5kHMK3M1faJ9F 7p45FKbZjwJ8ticpfqTcv0GSxLTxI90/jT8aNGtO/mnQpJ4qZOgfJ+TS7U+3bZsYs741 fCEsl0VmuQh9CeNCIBCaapPV3o1UuUYF1ZPIouozrdOtRhs3UjBiAqYa1WASiykI+Y9s EMQW7G7XB8IGNPXKbgnQqVCsQqZ0nc/JccrqNMpXFRkxOJkZ4KdbK7abvLj4xIStB4gF FtSg== Received: by 10.68.131.106 with SMTP id ol10mr1433957pbb.101.1332127319263; Sun, 18 Mar 2012 20:21:59 -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 z1sm10250017pbc.38.2012.03.18.20.21.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 20:21:58 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 18 Mar 2012 20:21:58 -0700 Date: Sun, 18 Mar 2012 20:21:58 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds Message-ID: <20120319032158.GG7731@localhost> References: <4F57DDB5.3090503@orlitzky.com> <20120308130310.69c3c714@pomiocik.lan> <4F58D6A5.7070804@orlitzky.com> <20120308182844.11201771@pomiocik.lan> <4F58F103.5010503@orlitzky.com> <20120308175345.2c4b72ff@googlemail.com> <4F58FC55.7070005@orlitzky.com> <20120308184820.108fc30c@googlemail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: cdd326ec-7d81-41ab-8c56-096a84232a60 X-Archives-Hash: f247105b5936c5d37edf3234bb2d8d00 On Mon, Mar 19, 2012 at 02:36:34PM +1300, Kent Fredric wrote: > On 19 March 2012 14:12, Steven J Long wrote: > > > > As for non-bash ebuilds, I have always agreed with antarus that they should > > simply use a different extension. Adding a new extension per source language > > is a *lot* cleaner than one per EAPI. > > Ok: If we take this notion and enshrine it in stone: > > If we assume Bash 4 is a seperate language from Bash 3, as its > syntax-backwards-incompatible, is it fair to suggest that for some > future EAPI which require Bash 4, that the extension change to suit? > > ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the > format is bash, and that '.ebuild4' is bash4 only? > > That way you have a forwards declaration of the syntax/file format > required to parse the file, but no declaration of the EAPI, so you're > not breaking encapsulation. > > This is breaking the direct file==eapi connection, but still > maintaining a loose file<->eapi connection. > > Its /sort/ of like the "one time extension change" proposal, except > its less 'arbitrary' than something like .eb , and it gives us the > future option of changing the suffix again if bash 5 comes out with > different syntax. > > Then we can do > > .ebuild = EAPI 0 - 4 & bash >= 3 > .ebuild4 = EAPI5 - 9 & bash >= 4 > .ebuild5 = EAPI10 - 15 & bash >= 5 > > Thoughts? This is a bad idea; it arbitrarily bleeds the bash version into the ebuild name, still requires an EAPI mechanism w/in the actual file, and is likely to break tools that have assumptions about extensions (even ones sooner or later written against such a setup). Besides; it's not bash version as much as global scope settings, functions, etc, that are the issue. Syntax is generally minor in comparison. ~harring