Paul de Vrieze <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 21 May 2006 12:38:49 +0200:
> This section is intended to convey that the maintainers of the primary > package manager can define (keeping the gentoo processes into account) new > extensions to the standard, or a new EAPI=1 version. I find the lack of a standard a huge sticking point ATM. Were we able to set back the clock and do things differently, I think most would agree that before working on a different implementation, defining a standard would have been a good thing. Be that as it may... This whole EAPI thing has bothered me a bit. We are now talking about defining EAPI=0, and later extensions EAPI=1, etc. In terms of EAPI support, I'd suggest the following convention: 1) Keep EAPI=0 as the target base and work to define it as some sort of standard. Obviously, this will continue beyond the present for some time as there's no current definition of a standard EAPI=0, beyond "what's in the tree at this moment". 2a) Beyond EAPI=0, that is, for extensions, don't just call them EAPI=1, Rather, a portage proposed implementation would be EAPI=portage-1, other implementations would be similar: EAPI=paludis-1, as an example. 2b) Alternative/refinement: Beyond EAPI=0, EAPI=1 when official. All unofficial extensions go with the RFC-familiar x- extension definition, so EAPI=x-paludis-1, EAPI=x-portage-multarch, whatever. At some point, an official EAPI=1 will be defined as a superset of x-portage-multiarch.3, x-paludis-thingy.2, x-thang-0.5, etc. 3) Official EAPI level in the tree. Overlays and package managers with their extensions will be have flexibility to define EAPI=x-whatever-ver as necessary. Ebuilds requiring these exotic EAPIs won't be allowed in the official tree, however, until adoption of an official EAPI version inclusive of the used extension. 4) This leaves a bit of flexibility in terms of what's allowed in the tree as compared to what any specific package manager supports, while restricting what's allowed in the tree to that supported by an officially defined EAPI level, thereby eventually and practically separating the tree from any specific package manager implementation. Package managers would need to be able to deal gracefully with unimplemented EAPIs by masking them and failing to process them further, but once an official EAPI level had been defined, ebuilds/eclasses/etc could use it and be in-standard, regardless of whether a particular package manager handled it or not. If the ebuild was within EAPI standard yet the package manager failed, it would be a package manager bug. If the ebuild/eclass/whatever did not meet standard, it would be an ebuild bug and the ebuild could be removed from the tree if it could not be brought into compliance. Obviously, this scenario assumes some form of EAPI=0 base is ultimately standardized and that progress can go on from there. However, in the mean time, extensions can still be defined as EAPI=x-whatever and overlays and package managers can begin to take advantage of them as such. It is recognized that some of these may yet make it into the as yet undefined EAPI=0 standard, and that as long as such a standard remains undefined, there WILL be some unavoidable instability as it's impossible to properly define what is allowed and what not, beyond what works with whatever package manager one might be using. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
