On Thu, 20 Dec 2007 03:31:14 +0100
Luca Barbato <lu_zero@g.o> 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.

-- 
Ciaran McCreesh