On Fri, 2006-06-02 at 19:48 +0200, Paul de Vrieze wrote: > On Friday 02 June 2006 18:47, Marius Mauch wrote: > > Actually this is probably the main problem of all the "package manager > > compability" gleps: We don't have a proper specification, all existing > > docs more or less are based on the existing portage implementation. So > > right now the implementation is the authorative specification, which of > > course creates some problems. > > IMO before any such glep can be considered we need a proper > > specification about our package and repository formats, otherwise you > > can't really validate any package manager (the statespace is a bit > > large for equivalence checks). > > The problem is actually that such a document is a living thing and it must > not > only exist initially but be maintained continuously.
Yes and no. EAPI=0 is somewhat nailed down. We could nail it down further. Any future EAPI versions could easily be written as just the differences from the previous EAPI. fex. EAPI=1 (or whatever) could be something like: all of EAPI=0 + multiple repositories (and a definition of requirements), USE-based dependencies (and a definition of requirements/etc), and per-package use.mask (including all the necessary information. Honestly, it is really bad that we do *not* have a listing of what is and what is not allowed in ebuilds. We have lots of different places where such things exist, but no one clear definition. We really need a single, concise definition of what exactly *is* an ebuild before trying to proceed further. Things to consider: - required variables (SRC_URI, DESCRIPTION, HOMEPAGE) - disallowed variables (P, T, PN) - valid non-function abilities (inherit is all that comes to mind) - description of default functions (as in what they are, not so much what they do in detail) I'm sure there's *tons* and *tons* more stuff, but this is a start. We do have quite a bit of this in the ebuild man page, os it isn't like we'd have to start from scratch. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
