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 1J4wjE-0004LH-QP for garchives@archives.gentoo.org; Wed, 19 Dec 2007 11:04:45 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBJB3lAw001032; Wed, 19 Dec 2007 11:03:47 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBJB0t22029494 for ; Wed, 19 Dec 2007 11:00:56 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5D12A64ECF for ; Wed, 19 Dec 2007 11:00:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 required=5.5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 e1SPt1QJRuE1 for ; Wed, 19 Dec 2007 11:00:49 +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 2A68E651EB for ; Wed, 19 Dec 2007 11:00:47 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J4wfC-0003dr-7R for gentoo-dev@gentoo.org; Wed, 19 Dec 2007 11:00:34 +0000 Received: from 82.152.194.118 ([82.152.194.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Dec 2007 11:00:34 +0000 Received: from slong by 82.152.194.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Dec 2007 11:00:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) Date: Wed, 19 Dec 2007 11:05:35 +0000 Message-ID: References: <200712172320.01988.peper@gentoo.org> <47671006.2020808@gentoo.org> <20071218001855.78c1864c@blueyonder.co.uk> <20071218013651.58f4f565@eusebe> <20071218172143.GB4423@ferdyx.org> <20071219102951.515beeca@blueyonder.co.uk> 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-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.194.118 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 1f36ffed-dcee-423b-9b2c-c35aaf27608c X-Archives-Hash: 69e171cccf0987782dcc846e8c8836ac Ciaran McCreesh wrote: > On Wed, 19 Dec 2007 10:26:16 +0000 > Steve Long wrote: >> Are you really telling me you are going to write _one_ ebuild >> with /that/ god-awful hackery in it? > > Are you really suggesting that no-one ever will? > They won't if the spec and the docs say it's restricted to a single instance, which can be checked trivially by repoman. The example given was contrived and not at all representative imo; for instance one could as easily do the same kind of thing with DESCRIPTION, but it would be of little use and just add confusion to no purpose. >> Sticking to a single EAPI="xx" format in the ebuild means we don't >> have the *hack* of duplicating information in the filename (and the >> whole {pre,post}src issue, QA checks for human error since this is >> redundant info) simply to avoid parsing a config file. > > There is no duplication of information, nor redundancy. > So what were the QA checks you mentioned to confirm that the same EAPI is set in both the filename and the ebuild, for-- if not integrity of duplicated data? > The pre/post source issue exists regardless of how EAPI is set -- it's > just that with filename EAPIs, you aren't restricted to post source > changes. And what benefit does that provide, besides making it easier for your package manager? (I note this is a technical consideration of the implementation, given as a reason to change a clean API-- with consequences for workflow.) > It's explicit in the GLEP because it's important that package > mangers get it right, but it's not a new issue. > Sure. > Ebuilds are not config files. > Indeed not, but they can be parsed as such for simple, core, metadata. > Really. It's a heck of a lot cleaner in the filename suffix. > Nah, it's an awful hack and you know it. It has nothing to do with package naming and is unnecessary exposure of internal data. -rN is ok, and there are rules on when and when not to bump rev; this is not. It's much cleaner specified as part of the ebuild in the same way as DESCRIPTION, so long as it is only specified once. Or do you see some real benefit to specifying EAPI more than once as in the example? If so, please share it. -- gentoo-dev@gentoo.org mailing list