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 1J5FdA-0003GV-KE for garchives@archives.gentoo.org; Thu, 20 Dec 2007 07:15: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 lBK7EmNZ007524; Thu, 20 Dec 2007 07:14:48 GMT Received: from smtp-out2.libero.it (smtp-out2.libero.it [212.52.84.42]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBK7CQVu004484 for ; Thu, 20 Dec 2007 07:12:26 GMT Received: from MailRelay09.libero.it (192.168.32.116) by smtp-out2.libero.it (7.3.120) id 4688F31B11D76B08 for gentoo-dev@lists.gentoo.org; Thu, 20 Dec 2007 08:12:26 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABakaUeXORDv/2dsb2JhbAAIqVw Received: from unknown (HELO [192.168.0.6]) ([151.57.16.239]) by outrelay-b09.libero.it with ESMTP; 20 Dec 2007 08:12:26 +0100 Message-ID: <476A1555.9020902@gentoo.org> Date: Thu, 20 Dec 2007 08:10:13 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.9 (X11/20071127) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) References: <200712172320.01988.peper@gentoo.org> <20071220003801.GL24034@supernova> <4769D3F2.1030204@gentoo.org> <20071220040753.31cf0c2e@blueyonder.co.uk> In-Reply-To: <20071220040753.31cf0c2e@blueyonder.co.uk> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: b11e367f-3fff-42f8-86a1-ff72a62a251a X-Archives-Hash: f4576efea74b2d4d6488e1230411d441 Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 03:31:14 +0100 > Luca Barbato wrote: >> Before spending even more time on it, could we try to come up with a >> definition of what eapi is, which problem is trying to solve and put >> that somewhere that isn't a long thread or an handful of threads >> scattered across mailing lists. > > An EAPI is a named set of rules telling a package manager how to deal > with a particular ebuild and related files, and telling ebuilds upon > what they may or may not rely from the package manager. It defines > aspects of package manager / ebuild relation including metadata, > environment and additional behavioural restrictions. > > EAPI names are not orderable and have no meaning to the package manager > other than their literal value. > > EAPIs may be entirely incompatible with each other, or they may be mere > extensions of a different EAPI, or they may be a subset of a different > EAPI, or any combination thereof. > > A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the > cat/pkg-ver as a whole, and is static across that cat/pkg-ver. > > EAPI is part of a cat/pkg-ver's metadata. All existing EAPIs require > that EAPI follows the environment invariancy rules. > > If a package manager does not support a particular EAPI, the > *only* thing it may assume is that it does not support that particular > EAPI. It may not assume that it knows what any aspect of that > cat/pkg-ver's metadata is, nor may it assume that it knows what cat, > pkg or ver are. Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? About the problem it is trying to solve, I think it basically boils down to make sure the package manager: - ignores ebuilds with syntax different from the one it can handle - can be safely updated even in the situation the tree has ebuilds it cannot parse. eapi, as defined above, does address those point in the best way? those point are what we are trying to address with eapi? -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list