From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lbhlk-0001ex-Ar for garchives@archives.gentoo.org; Mon, 23 Feb 2009 20:51:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6DCE7E04EE; Mon, 23 Feb 2009 20:51:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 31771E04EE for ; Mon, 23 Feb 2009 20:51:14 +0000 (UTC) Received: from [192.168.0.9] (unknown [151.57.3.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 3F1EAB5AA6 for ; Mon, 23 Feb 2009 20:51:13 +0000 (UTC) Message-ID: <49A30C3F.2030209@gentoo.org> Date: Mon, 23 Feb 2009 21:51:11 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) References: <1234257125.18160.2016.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> <49A2B276.1000109@gentoo.org> <49A2C40D.3060601@gentoo.org> <20090223132202.1cd1337e@halo.dirtyepic.sk.ca> In-Reply-To: <20090223132202.1cd1337e@halo.dirtyepic.sk.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1fef7dcd-17f4-4b96-ad1b-5b5643bb9df9 X-Archives-Hash: f1f4aebce50b20d098d40bcb4a9c2709 Ryan Hill wrote: > On Mon, 23 Feb 2009 08:43:09 -0700 > Steve Dibb wrote: > >> Richard Freeman wrote: >>> I still don't see why we need to be encoding metadata in filenames. >>> PERL doesn't care what a file extension is, python doesn't care, >>> bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even >>> ld-linux.so doesn't care. I'm sure that in at least some of these >>> cases they end up parsing parts of the file twice - once to figure >>> out what it is, and the second time to actually handle it. I'm >>> actually hard pressed to think of any unix-based software that uses >>> the filename to store a mandatory file format versioning specifier >>> of some kind. > > $ ls /usr/lib ldconfig ? >> I have to admit I'm in the same camp with Richard, and don't >> understand the necessity. I'm also opposed to creating arbitrary >> suffixes to the ebuild extension, for cosmetic and compatibility >> reasons. >> >> Plus, I don't really grasp the whole "we have to source the whole >> ebuild to know the EAPI version" argument. It's one variable, in one >> line. Can't a simple parser get that and go from there? > > Not really. Let's play Guess the EAPI. :o > > 1. > ----- > EAPI=1 > ---- > > 2. (with myeclass.eclass containing EAPI=2) > ----- > EAPI=1 > inherit myeclass Invalid > ----- > > 3. (with myeclass.eclass containing EAPI=2) > ----- > EAPI=5 > inherit myeclass Invalid > So you see, it's not as easy as a grep command. You need to source the > ebuild to know how things like inherit will affect the environment. > And without knowing the EAPI, you don't know which version of inherit to > call. It it isn't invalid already... > > (i hope i have this right. feel free to call me names if i don't) Names! lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero