--- xml/htdocs/proj/en/glep/glep-0033.html 2009/02/20 09:19:56 1.9 +++ xml/htdocs/proj/en/glep/glep-0033.html 2010/04/07 22:04:22 1.10 @@ -4,10 +4,9 @@- +
|Author:||Brian Harring <ferringb at gentoo.org>, John Mylchreest <johnm at gentoo.org>|
Approved by the Gentoo Council on 15 September 2005. As of Sept. 2006 this GLEP is on hold, pending future revisions.
For any design, the transition from theoretical to applied exposes inadequacies in the original design. This document is intended to document, and propose a revision of the current eclass setup to address current eclass inadequacies.@@ -83,14 +82,14 @@ In general, a large scale restructuring of what eclasses are and how they're implemented. Essentially version two of the eclass setup.
From this point on, the proposed eclass setup will be called 'new eclasses', the existing crop (as of this writing) will be referenced as 'old eclasses'. The distinction is elaborated on within this document.
Eclasses within the tree currently are a bit of a mess- they're forced to maintain backwards compatibility w/ all previous functionality. In effect, their api is constant, and can only be added to- never changing the existing @@ -126,13 +125,13 @@
Consider the majority of the portage bin/* scripts- these all are candidates for being added to the tree as elibs, as is the bulk of eutils.
The various parts of this proposal are broken down into a set of changes and elaborations on why a proposed change is preferable. It's advisable to the reader that this be read serially, rather then jumping around.-
As briefly touched upon in Motivation and Rationale, the original eclass design allowed for the eclass to modify the metadata of an ebuild, metadata being the DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, @@ -201,8 +200,8 @@ possible to avoid any ambiguity related to them. The intention is to make it clear, such that no misconceptions occur, resulting in bugs.
Since elibs are now intended on holding common bash functionality, the focus of eclasses should be in defining an appropriate template for ebuilds. For example, defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. @@ -240,8 +239,8 @@ elaborated in the next section) can be removed from the tree once they're no longer in use.
With current eclasses, once the eclass is in use, its api can no longer be changed, nor can the eclass ever be removed from the tree. This is why we still have ancient eclasses that are completely unused sitting in the tree, for @@ -283,8 +282,8 @@
In other words, these new eclasses would in effect, be old eclasses since older portage versions could still access them.
There are only two way to block the existing (as of this writing) inherit functionality from accessing the new eclasses- either change the extension of eclasses to something other then 'eclass', or to have them stored in a separate @@ -333,8 +332,8 @@ applications of a cattle prod)- these are strictly automatic checks, akin to repoman's dependency checks.
As clarified above, new eclasses will exist in a separate directory that will be intentionally inaccessible to the inherit function. As such, users of older portage versions will have to upgrade to merge any ebuild that uses elibs/new @@ -392,8 +391,8 @@ is akin, exempting the fact we're providing a way to make the eggs whole again (the king's men would've loved such an option).
As has been done in the past whenever a change in the tree results in ebuilds requiring a specific version of portage, as ebuilds migrate to the new eclasses, they should depend on a version of portage that supports it. From the users @@ -421,8 +420,8 @@ advantage of it. :)
All backwards compatibility issues are addressed in line, but a recap is offered- it's suggested that if the a particular compatibility issue is questioned/worried over, the reader read the relevant section. There should be @@ -453,19 +452,18 @@ above.