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 1LaGKa-0003qv-N1 for garchives@archives.gentoo.org; Thu, 19 Feb 2009 21:21:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BCAA4E0465; Thu, 19 Feb 2009 21:21:14 +0000 (UTC) Received: from mail-bw0-f157.google.com (mail-bw0-f157.google.com [209.85.218.157]) by pigeon.gentoo.org (Postfix) with ESMTP id 5A326E0465 for ; Thu, 19 Feb 2009 21:21:14 +0000 (UTC) Received: by bwz1 with SMTP id 1so1692960bwz.10 for ; Thu, 19 Feb 2009 13:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=KWzumkVDnXaVBKgkcDq6d/Vr/xD9HL/4Enyt3EcBKto=; b=nZbox53mUofoJFnRiqFCWlOzqd7sfcZcsXMGqinkZUbFetJMAswpUOxyjgWCX8YHJF GlKnSEi07ly8Eay/hyQuhvUL6UqBYz33EhRH+ZC8l8XEIv5Abxw8QYpvMZBRdopV0YP1 UWLwRPtkml+pOydJIQ7+vXcmLZ49AY5kew2CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=L0pElCg8C2t6uPGnFxlPAglJKOireUZzrpMwpWwR7OkSjmJ8n1K8ezhipa15JPtcI6 ZakMp7LlYoa4muVibYIS9EJto+3Ygq+ChlJWfeF7N7Ev+iIbmR3DO2dDoloEwTV/UYl4 iny8W8ageI+pWQ1JSUt0zBt220yeIbaBSllgI= Received: by 10.223.126.69 with SMTP id b5mr824661fas.107.1235078473451; Thu, 19 Feb 2009 13:21:13 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id k1sm4901459ugf.55.2009.02.19.13.21.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:21:13 -0800 (PST) Date: Thu, 19 Feb 2009 21:21:06 +0000 From: Ciaran McCreesh To: Peter Volkov Cc: gentoo-council@lists.gentoo.org Subject: Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009 Message-ID: <20090219212106.58e8f2dd@snowcone> In-Reply-To: <1235077892.13198.1923.camel@localhost> References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/gduSgj368xHpt8FZ_OEHNC4"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 57839b2a-7403-42df-88c3-8dea755025a3 X-Archives-Hash: 214e4b1860876823816dea033eb3675b --Sig_/gduSgj368xHpt8FZ_OEHNC4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 20 Feb 2009 00:11:32 +0300 Peter Volkov wrote: > Filename extension is a "suffix to the name of a computer file, > designed to show its format" (-- wikipedia). General format of > ebuilds is bash. Putting version of bash scripts inside filename > extension just breaks common convention people got accustomed to. Ebuilds are written in a domain specific language that's built on top of bash. Hence why we use .ebuild, not .bash... An EAPI can be thought of as a version of that DSL, so it's just like .mp3. > You don't need to parse full bash script. You just need to get >=20 > EAPI=3D"something" >=20 > string from there. If you wish to implement new ebuild format, e.g. > ebuilds in xml, in such a case you'll change extension on .xebuild or > whatever suits better. Except with current rules, the only way you can get that EAPI=3Dsomething string is to evaluate the entire ebuild inside a special environment that already knows the EAPI up-front. > > Another cache won't solve anything since there's no way to generate > > that cache to begin with -- and a second level of cache would slow > > things down, not speed them up. >=20 > I told about caching just to avoid "it's slow to get EAPI from ebuild" > argument. Uh. So you don't understand the metadata generation process at all then? > That said, technically there are other solutions for this problem, > e.g. 1) it is possible to read one line of defined format from any > file No it isn't. The only way to get the EAPI from an ebuild is to evaluate it in an environment where EAPI is already known. > 2) it is possible to make eapi inside ebuild name > (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even > breaking compatibility solution, we could already start using if we > had forgotten about GLEP 55 long time ago... This is just the same as GLEP 55, except that it breaks current package managers and is more typing. In other words, it's a bad solution. > Putting GLEP 55 infinite number of times on council agenda makes me > feel that this issue has something common with perpetuum mobile. At > least I'd like similar resolution from our council as the Royal > Academy of Sciences in Paris did in 1775. It's hard to tell anything > new about GLEP 55 but people still don't like it, so, council, > please, ban it forever and let something else arise. GLEP 55 is necessary, and there *still* haven't been any legitimate technical objections to it, nor have there been any viable alternatives proposed. --=20 Ciaran McCreesh --Sig_/gduSgj368xHpt8FZ_OEHNC4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmdzUQACgkQ96zL6DUtXhG6RwCfTb8RQoFm/dz61xoL9gKBVVdO +k0AnRm8+uv1QUF6JEkCTvYOqdX4mXry =lBba -----END PGP SIGNATURE----- --Sig_/gduSgj368xHpt8FZ_OEHNC4--