[gentoo-dev] Re: RFC: GLEP 49 - Package manager requirements

[Duncan]

Paul de Vrieze <pauldv@g.o> posted
200605211238.56080.pauldv@g.o, 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@g.o mailing list