--- 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 @@ Title:Eclass Restructure/Redesign -Version:1.3 +Version:1.5 -Last-Modified:2005/03/06 20:39:19 +Last-Modified:2005/09/15 21:02:11 Author:Brian Harring <ferringb at gentoo.org>, John Mylchreest <johnm at gentoo.org> -Status:Draft +Status:Approved Type:Standards Track @@ -46,7 +46,7 @@ Created:29-Jan-2005 -Post-History:29-Jan-2005 6-Mar-2005 +Post-History:29-Jan-2005 6-Mar-2005 15-Sep-2005 @@ -54,24 +54,29 @@

Contents

+
+

Status

+

Approved by the Gentoo Council on 15 September 2005.

+
-

Abstract

+

Abstract

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.

-

Terminology

+

Terminology

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.

-

Motivation and Rationale

+

Motivation and Rationale

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.

-

Specification

+

Specification

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.

-

Ebuild Libraries (elibs for short)

+

Ebuild Libraries (elibs for short)

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.

-

The reduced role of Eclasses, and a clarification of existing Eclass requirements

+

The reduced role of Eclasses, and a clarification of existing Eclass requirements

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.

-

The end of backwards compatibility...

+

The end of backwards compatibility...

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.

-

Tree restructuring

+

Tree restructuring

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.

-

The start of a different phase of backwards compatibility

+

The start of a different phase of backwards compatibility

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).

-

Migrating to the new setup

+

Migrating to the new setup

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 @@

-

Backwards Compatibility

+

Backwards Compatibility

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 @@

@@ -460,7 +465,7 @@