--- xml/htdocs/proj/en/glep/glep-0033.html 2005/09/15 02:37:38 1.3 +++ xml/htdocs/proj/en/glep/glep-0033.html 2005/09/15 21:04:13 1.4 @@ -32,13 +32,13 @@
Approved by the Gentoo Council on 15 September 2005.+
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.@@ -82,13 +87,13 @@ 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 @@ -125,12 +130,12 @@ 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, @@ -200,7 +205,7 @@ 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. @@ -239,7 +244,7 @@ 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 @@ -282,7 +287,7 @@ 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 @@ -332,7 +337,7 @@ 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 @@ -391,7 +396,7 @@ (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 @@ -420,7 +425,7 @@
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 @@ -452,7 +457,7 @@