Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato <lu_zero@gentoo.org>]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 03:31:14 +0100
> Luca Barbato <lu_zero@gentoo.org> 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