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 1J6mf1-0007Ol-3t for garchives@archives.gentoo.org; Mon, 24 Dec 2007 12:43:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBOCgmD4004850; Mon, 24 Dec 2007 12:42:48 GMT Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.226]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBOCcxYd031644 for ; Mon, 24 Dec 2007 12:39:23 GMT Received: by hu-out-0506.google.com with SMTP id 23so1701981huc.1 for ; Mon, 24 Dec 2007 04:39:23 -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:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; bh=4GjFSQL1OGkHCvEz+/JsS1CzRsnBM9KZnaG7COuydvE=; b=imHcSUZBXwc2KFpGyitaSu5N0/3oJnrLnGKqU2bD8A9S33oJ+ThDIGzf1nOPjyRi/Q2OsvPu38SwCcwqT8OLifZTCecUJQdud1ScMgFQK9hT9nz4zkX9gN6DsMqCLYsOBVjxHjdzvXLZO6FCzIHNfpqhi+ErBWNXzF/g5f1cw/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=nmveTxZhg0MHBsg3erq9/AY0MbVdpUBbG2QweeV8CovrJRkpKQaW69wCnLYDfJ5/f8kPa66RbC6WBKftbmBRcdUJJV2jgK77I/RfTUVqRFeDs6Z8QafEGAzFsextGRL3taZAsmqP8QDEf94ahizTQPak2NPQJbtfOF8FHCmVzAo= Received: by 10.67.116.16 with SMTP id t16mr3525735ugm.55.1198499963415; Mon, 24 Dec 2007 04:39:23 -0800 (PST) Received: from localhost ( [213.121.151.206]) by mx.google.com with ESMTPS id 13sm6630287ugb.0.2007.12.24.04.39.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2007 04:39:22 -0800 (PST) Date: Mon, 24 Dec 2007 12:39:17 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) Message-ID: <20071224123917.50e6f524@googlemail.com> In-Reply-To: References: <200712172320.01988.peper@gentoo.org> <47692CB8.1050006@gentoo.org> <20071219110544.55ec45be@altair.jimramsay.com> <476AB9E0.5030702@gentoo.org> <20071221005153.730a154d@blueyonder.co.uk> <476B2C02.20606@gentoo.org> <20071221030704.0d1eb3e2@blueyonder.co.uk> <476B8E37.2060506@gmail.com> <20071221100137.421d5934@blueyonder.co.uk> <476BBFB5.1000908@gentoo.org> <20071221133807.300642e3@blueyonder.co.uk> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.1; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: c202aee8-9de6-4334-9d0c-4ff4ab2159b0 X-Archives-Hash: cff02131c17c9211fbd3f33b4653158f On Mon, 24 Dec 2007 11:19:18 +0000 Steve Long wrote: > > Which is fine. But then, the majority of devs shouldn't expect to be > > able to provide opinions when it comes to the more technical > > aspects. > > > Yes, but they can smell a nasty hack when they see one; starting with > the fact that the API is no longer as clean. Clearly not... > >> On a somewhat related note : I noticed that among the massive > >> thread, you have brought up several times the issue of cache > >> generation, saying that it was a complicated process. > >> > >> Maybe this process needs to be reworked before the whole EAPI issue > >> can be resolved? > > > > That's partly what the GLEP is doing. Making it any simpler, > > unfortunately, would involve either a huuuuuuge performance hit > > (we're talking two orders of magnitude here) or removing metadata > > from the ebuilds entirely -- neither of which are viable solutions. > > > Oh, I thought this wasn't about performance? Nor indeed about cache > generation. The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. In particular, making a typical emerge -pv world take of the order of 0.1s per c/p-v's metadata that's needed (as a very rough idea, we're talking a thousand upwards of these on a typical system) isn't even remotely feasible. And no, the GLEP doesn't directly address cache generation. But equally, it can't ignore it simply because without some form of static metadata cache package managers can't be implemented in a way acceptable to end users. You see, there's this thing called the "big picture"... -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list