From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J5Q4R-0007kz-JN for garchives@archives.gentoo.org; Thu, 20 Dec 2007 18:24:36 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBKINXc2010414; Thu, 20 Dec 2007 18:23:33 GMT Received: from crux.i-cable.com (crux.i-cable.com [203.83.115.104]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBKILPxC008000 for ; Thu, 20 Dec 2007 18:21:26 GMT Received: (qmail 607 invoked by uid 107); 20 Dec 2007 18:21:24 -0000 Received: from 203.83.114.122 by crux (envelope-from , uid 104) with qmail-scanner-2.01 (clamdscan: 0.90.3/4349. spamassassin: 2.63. Clear:RC:1(203.83.114.122):SA:0(2.6/5.0):. Processed in 7.428519 secs); 20 Dec 2007 18:21:24 -0000 X-Spam-Status: No, score=2.6 required=5.0 X-Spam-Level: ++ Received: from ip114122.hkicable.com (HELO xenon.i-cable.com) (203.83.114.122) by 0 with SMTP; 20 Dec 2007 18:21:16 -0000 Received: from [192.168.1.100] (cm222-167-208-85.hkcable.com.hk [222.167.208.85]) by xenon.i-cable.com (8.13.5/8.13.5) with ESMTP id lBKILFA5003343; Fri, 21 Dec 2007 02:21:16 +0800 (CST) Message-ID: <476AB320.4010700@gentoo.org> Date: Fri, 21 Dec 2007 02:23:28 +0800 From: Zhang Le User-Agent: Thunderbird 2.0.0.9 (X11/20071123) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org CC: ciaran.mccreesh@blueyonder.co.uk Subject: Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) References: <200712172320.01988.peper@gentoo.org> <47671006.2020808@gentoo.org> <20071218001855.78c1864c@blueyonder.co.uk> <20071218013651.58f4f565@eusebe> <20071218172143.GB4423@ferdyx.org> <20071219102951.515beeca@blueyonder.co.uk> <4769790A.2000401@gentoo.org> <4769B073.2030508@thefreemanclan.net> <20071220000627.29426d0c@blueyonder.co.uk> <4769C557.106@thefreemanclan.net> <20071220035400.7ef9c32b@blueyonder.co.uk> <20071220095725.0dc2c76f@blueyonder.co.uk> In-Reply-To: <20071220095725.0dc2c76f@blueyonder.co.uk> X-Enigmail-Version: 0.95.5 OpenPGP: id=1E4E2973 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 6c591ca3-98ff-41ea-ae1b-25c117a90d24 X-Archives-Hash: 641d7df94456de1c2ede7117a85ae708 Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 09:43:59 +0000 (UTC) > Duncan <1i5t5.duncan@cox.net> wrote: >>> Because a) a future EAPI might want to change EAPI into a function >>> rather than a variable, b) there are a zillion ways of setting a >>> variable in bash and people already use all of them and c) >>> introducing new weird format requirements is silly. >> So you're proposing putting the function into the filename? > > No, I'm saying that the data goes into the filename. then why not let it go into the file content? if data goes into file content, then function is not needed you are contradicting with yourself here. > >> As he stated, the only credible reason (so far given) bash must be >> used to parse EAPI is if it's dynamic, say a function, and that won't >> work so well in a filename either. > > No no no. Bash is the only thing that can parse bash. Ebuilds are bash. Getting the first line of a file using whatever language is just a piece of cake. And I don't see why setting a rule on the syntax of EAPI definition is so silly. How many ways to define a variable in bash can you think of? Is it that hard to come up with a way to normalized the definition? Just like charset code normalization, e.g. from UTF-8 to utf8? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- gentoo-dev@gentoo.org mailing list