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 1S9R7p-0000UD-C8 for garchives@archives.gentoo.org; Mon, 19 Mar 2012 01:11:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D25FCE09D4; Mon, 19 Mar 2012 01:10:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3C793E0788 for ; Mon, 19 Mar 2012 01:10:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B8E81643ED for ; Mon, 19 Mar 2012 01:10:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5.5 tests=[AWL=-1.331, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFVvrEX12hN3 for ; Mon, 19 Mar 2012 01:10:01 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4483D1B4023 for ; Mon, 19 Mar 2012 01:09:59 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S9R6j-00048q-OZ for gentoo-dev@gentoo.org; Mon, 19 Mar 2012 02:09:57 +0100 Received: from 109.176.204.35 ([109.176.204.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Mar 2012 02:09:57 +0100 Received: from slong by 109.176.204.35 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Mar 2012 02:09:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: RFD: EAPI specification in ebuilds Date: Mon, 19 Mar 2012 01:12:05 +0000 Organization: Friendly-Coders Message-ID: References: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> <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="UTF-8" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.204.35 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 19c9440d-d895-4dc1-991c-709b90aeb0a2 X-Archives-Hash: a46e8f54d5cb7e872e851df0c1af9f04 Firstly, wrt probing the ebuild for EAPI=3D.. I'd just like to point out = that=20 a regex is not required during the scan, and nor is restricting it to the= =20 first N lines, though the latter may be desirable and could trivially=20 exclude comment and whitespace-only or empty lines. Ciaran McCreesh wrote: >Michael Orlitzky wrote: >> Fair enough, but aren't you arguing the opposite point with Zac? If >> ebuilds are data, fine, we write EAPI=3D4 somewhere and be done with >> it. Anything not having that format is out-of-spec. >=20 > The problem is that right now there's no way to determine the format of > the data until you already know the format of the data. Well, we know it's bash.. ;) > We hack around > this by not allowing "drastic" format changes, where "drastic" includes > "using things in newer versions of bash" and "not adding new global > scope commands". >=20 > The question under discussion is whether we a) keep "what format the > data is in" as being part of the data, but impose some strange and > arbitrary conditions on it Stipulating an allowed set of characters is in no way arbitrary, nor=20 strange- we already have similar restrictions on category and package nam= es,=20 versions, keywords and USE flags, for example. Requiring that the EAPI=20 assignment for a bash .ebuild must be a literal (ie EAPI=3D"foo" or EAPI=3D= foo=20 or EAPI=3D'foo') at the start of a line, is not hard to understand; as yo= u=20 said ebuild authors already have to deal with lots of other subtle=20 restrictions. As Marc Schiffbauer said, EAPI "might be the most important= =20 constraint in an ebuild at all" (from this and earlier discussion, it's=20 clear that it definitely is) -- ebuild developers have to know about it, = and=20 this is a simple, clear restriction. Micha=C5=82 G=C3=B3rny stated: "The = most=20 important ebuild variables like EAPI should be readable on sight, without= =20 having to lookup random variables, functions etc" and in fact, all ebuild= s=20 in the tree already use a string literal- it just makes more sense from a= =20 code readability pov, quite apart from anything else. You mentioned indentation in another mail; afaics there is no problem wit= h=20 whitespace at the start of the line. Ensuring EAPI declaration and sourced value match, has value beyond use i= n=20 EAPI extraction: it's a sanity check that should be performed in any case= ,=20 way before an ebuild hits the tree. > , b) make a one-time change to have some kind > of 'header' inside the file describing its format that isn't really par= t > of the data itself, or c) admit that GLEP 55 already solved the problem > and we might as well just fix the issue properly once and for all, even > if GLEP 55's author is considered by some to be one of Satan's little > minions. >=20 Regardless of your past behaviour, my objections to GLEP 55 are, and alwa= ys=20 have been, technical: it breaks encapsulation, which once implemented can= not=20 be taken back. It results in a mess of filename extensions, which are=20 confusing and irrelevant to end-users, as well as making other tools and=20 scripts trickier to implement; a simple example: a highlighting editor wo= uld=20 need to pattern-match the file extension. It's not needed: the simplest,=20 least-invasive alternative already works, and should have been adopted ye= ars=20 ago, when the Council asked for alternatives to be tried. The tree is=20 clearly in shape to do so now, though. Package versions have to be in the filename to avoid collisions, and inde= ed=20 the information is relevant to both end-users and developers. EAPI, while= =20 vital to the mangler and of immediate concern to developers, matches neit= her=20 of those. Since it is of immediate concern, restricting it to a string=20 literal makes sense from both maintenance (which is why it matches tree- usage) and implementation perspectives. And specifying what characters ar= e=20 allowed is a no-brainer; it's odd that that still has not been done, desp= ite=20 it also being a requirement for embedding EAPI in filenames. Your motivation for GLEP-55 states: "In order to get the EAPI the package= =20 manager needs to source the ebuild." Given a suitable specification, that= =20 isn't the case. repoman checks and explicit documentation are all that's=20 needed beyond that. As for non-bash ebuilds, I have always agreed with antarus that they shou= ld=20 simply use a different extension. Adding a new extension per source langu= age=20 is a *lot* cleaner than one per EAPI. Regards, Steve. --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)