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 1La5o9-0005Gc-4T for garchives@archives.gentoo.org; Thu, 19 Feb 2009 10:07:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FB7CE0229; Thu, 19 Feb 2009 10:07:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6A8CEE0229 for ; Thu, 19 Feb 2009 10:07:04 +0000 (UTC) Received: from [192.168.2.4] (unknown [79.120.41.51]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 2EFBAB4B1D; Thu, 19 Feb 2009 10:07:02 +0000 (UTC) Subject: Re: [gentoo-council] Preliminary Meeting-Topics for 12 February 2009 From: Peter Volkov To: Ciaran McCreesh Cc: gentoo-council@lists.gentoo.org In-Reply-To: <20090212180350.0d9a9df5@snowcone> 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> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 Feb 2009 13:06:01 +0300 Message-Id: <1235037961.13198.779.camel@localhost> 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 X-Mailer: Evolution 2.24.4 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: bd1081ee-d12a-4aab-a717-a26ce29d9458 X-Archives-Hash: 1d764de883abecde7fc6bf706923be64 =D0=92 =D0=A7=D1=82=D0=B2, 12/02/2009 =D0=B2 18:03 +0000, Ciaran McCreesh= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > GLEP 55 *is* the good, workable solution. There still haven't been > legitimate any technical objections to it. This issue was discussed already... [1] If you and think that EAPI is meta-information then it should not be inside file name and then it's possible to parse ebuild and get EAPI from some defined-format line. Performance penalties can be mitigated by some new caching (you know better than me that it's good idea to re-implement caching in any case). If it's not meta-information and can be put inside file name, then put it differently, not inside extension. It "breaks current package managers" is not an argument since it's possible to change format now and we'll have this feature later. We are already discussing this feature more than year. Many people voiced concerns about .eapi extension so why don't you try fix same issue differently? Yes it's harder and probably longer but I don't believe it's impossible. [1] http://archives.gentoo.org/gentoo-dev/msg_95f3b65a36aaa5aa9635a7f8cb1= b7592.xml --=20 Peter.