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 1J9ME9-0000cL-CZ for garchives@archives.gentoo.org; Mon, 31 Dec 2007 15:06:53 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBVF5XP0012363; Mon, 31 Dec 2007 15:05:33 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 lBVEw51G030814 for ; Mon, 31 Dec 2007 14:58:34 GMT Received: from unknown (p54A645C4.dip.t-dialin.net [84.166.69.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 27587651DF for ; Mon, 31 Dec 2007 14:44:46 +0000 (UTC) Date: Mon, 31 Dec 2007 15:46:06 +0100 From: Marius Mauch To: gentoo-dev@lists.gentoo.org Subject: Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) Message-Id: <20071231154606.158aea1e.genone@gentoo.org> In-Reply-To: <20071228120312.453248dd@blueyonder.co.uk> References: <200712172320.01988.peper@gentoo.org> <20071220003801.GL24034@supernova> <4769D3F2.1030204@gentoo.org> <20071220040753.31cf0c2e@blueyonder.co.uk> <476A1555.9020902@gentoo.org> <20071227201614.8bd1175a.genone@gentoo.org> <47742693.2010909@gentoo.org> <20071228120312.453248dd@blueyonder.co.uk> Organization: Gentoo X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.6.10; i686-pc-mingw32) 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: 521a24c2-1e35-4e10-9e64-871eeb7e281f X-Archives-Hash: ba086e1ac54a07fa890065b6c6c262ae On Fri, 28 Dec 2007 12:03:12 +0000 Ciaran McCreesh wrote: > On Thu, 27 Dec 2007 23:26:27 +0100 > Luca Barbato wrote: > > Marius Mauch wrote: > > > Nope. EAPI (from my POV) defines the API that a package manager has > > > to export to an ebuild/eclass. That includes syntax and semantics > > > of exported and expected functions and variables (IOW the content > > > of ebuilds/eclasses), but does not contain naming and versioning > > > rules (as those impact cross-package relationships). > > > > This restricted definition is ok for everybody? > > The restricted definition is certainly OK, but I'm not convinced that > the restriction is necessary. There's no particular reason that new > version formats can't be introduced in a new EAPI so long as the > version strings don't appear in ebuilds using older EAPIs or in > profiles. The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? > Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Marius -- gentoo-dev@gentoo.org mailing list