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

[Marius Mauch]

On Fri, 28 Dec 2007 12:03:12 +0000
Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote:

> On Thu, 27 Dec 2007 23:26:27 +0100
> Luca Barbato <lu_zero@g.o> 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@g.o mailing list