On Thu, 20 Dec 2007 03:31:14 +0100 Luca Barbato <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature