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 1LbgMd-0006PS-O1 for garchives@archives.gentoo.org; Mon, 23 Feb 2009 19:21:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AFB46E0404; Mon, 23 Feb 2009 19:21:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 68E34E0404 for ; Mon, 23 Feb 2009 19:21:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BE614B58F5 for ; Mon, 23 Feb 2009 19:21:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 required=5.5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BA6WHbhqRwIF for ; Mon, 23 Feb 2009 19:21:07 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id CC447B5B4D for ; Mon, 23 Feb 2009 19:21:03 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LbgMM-00029Y-8b for gentoo-dev@gentoo.org; Mon, 23 Feb 2009 19:20:58 +0000 Received: from s0106001f3b27dbf9.mj.shawcable.net ([70.64.208.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 19:20:58 +0000 Received: from dirtyepic by s0106001f3b27dbf9.mj.shawcable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 19:20:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Date: Mon, 23 Feb 2009 13:22:02 -0600 Message-ID: <20090223132202.1cd1337e@halo.dirtyepic.sk.ca> 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> 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: multipart/signed; boundary="Sig_/V7/oUhRWIr27r2CvIr4XW.E"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: s0106001f3b27dbf9.mj.shawcable.net X-Newsreader: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Sender: news X-Archives-Salt: e435893b-b4e2-4eb7-942c-481399e9ba94 X-Archives-Hash: 2a1036eaa41de759ac08f870e4367b6f --Sig_/V7/oUhRWIr27r2CvIr4XW.E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 > 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. >=20 > 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=3D1 ---- 2. (with myeclass.eclass containing EAPI=3D2) ----- EAPI=3D1 inherit myeclass ----- 3. (with myeclass.eclass containing EAPI=3D2) ----- EAPI=3D5 inherit myeclass ----- 1. 1 (simple enough) 2. 2 (because myeclass.eclass sets EAPI=3D2) 3. 5 (inherit was changed in EAPI 5 to not overwrite ${EAPI} if already set in an ebuild) 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. (i hope i have this right. feel free to call me names if i don't) --=20 gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 --Sig_/V7/oUhRWIr27r2CvIr4XW.E Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmi91oACgkQiqiDRvmkBmKyLACgokKwdIfDc7ZPfAmJQlNZzP6y 61oAn1zObTf0kL7NBgZuOezsxHD63kfI =2WUk -----END PGP SIGNATURE----- --Sig_/V7/oUhRWIr27r2CvIr4XW.E--