/[gentoo]/xml/htdocs/proj/en/glep/glep-0033.txt
Gentoo

Diff of /xml/htdocs/proj/en/glep/glep-0033.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.2 Revision 1.3
1GLEP: 33 1GLEP: 33
2Title: Eclass Restructure/Redesign 2Title: Eclass Restructure/Redesign
3Version: $Revision: 1.2 $ 3Version: $Revision: 1.3 $
4Last-Modified: $Date: 2005/03/06 20:33:20 $ 4Last-Modified: $Date: 2005/03/06 20:39:19 $
5Author: Brian Harring <ferringb@gentoo.org>, John Mylchreest <johnm@gentoo.org> 5Author: Brian Harring <ferringb@gentoo.org>, John Mylchreest <johnm@gentoo.org>
6Status: Draft 6Status: Draft
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Created: 29-Jan-2005 9Created: 29-Jan-2005
10Post-History: 29-Jan-2005 10Post-History: 29-Jan-2005 6-Mar-2005
11 11
12 12
13Abstract 13Abstract
14======== 14========
15 15
126of elibs gives you the functionality for all phases, except for depends- depends being the 126of elibs gives you the functionality for all phases, except for depends- depends being the
127only phase that is capable of specifying metadata. Second, as an added bonus, late 127only phase that is capable of specifying metadata. Second, as an added bonus, late
128loading reduces the amount of bash sourced for a regen- faster regens. This however is minor, 128loading reduces the amount of bash sourced for a regen- faster regens. This however is minor,
129and is an ancillary benefit of the first reason. 129and is an ancillary benefit of the first reason.
130 130
131There are a few further restrictions with elibs- mainly, elibs to load can only be specified 131There are a few further restrictions with elibs--mainly, elibs to load can only be specified
132in either global scope, or in the setup, unpack, compile, test, and install phases. You can 132in either global scope, or in the setup, unpack, compile, test, and install phases. You can
133not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases, 133not load elibs in prerm, postrm, preinst, and postinst. The reason being, for \*rm phases,
134installed pkgs will have to look to the tree for the elib, which allows for api drift to cause 134installed pkgs will have to look to the tree for the elib, which allows for api drift to cause
135breakage. For *inst phases, same thing, except the culprit is binpkgs. 135breakage. For \*inst phases, same thing, except the culprit is binpkgs.
136 136
137There is a final restriction- elibs cannot change their exported api dependent on the api 137There is a final restriction--elibs cannot change their exported api dependent on the api
138(as some eclass do for example). The reason mainly being that elibs are loaded once- not 138(as some eclass do for example). The reason mainly being that elibs are loaded once--not
139multiple times, as eclasses are. 139multiple times, as eclasses are.
140 140
141To clarify, for example this is invalid. 141To clarify, for example this is invalid.
142:: 142::
143
143 if [[ -n ${SOME_VAR} ]]; then 144 if [[ -n ${SOME_VAR} ]]; then
144 func x() { echo "I'm accessible only via tweaking some var";} 145 func x() { echo "I'm accessible only via tweaking some var";}
145 else 146 else
146 func x() { echo "this is invalid, do not do it."; } 147 func x() { echo "this is invalid, do not do it."; }
147 fi 148 fi
441a more in depth discussion of the issue, along with a more extensive explanation 442a more in depth discussion of the issue, along with a more extensive explanation
442of the potential solutions, and reasons for the chosen solution. 443of the potential solutions, and reasons for the chosen solution.
443 444
444To recap: 445To recap:
445:: 446::
447
446 New eclasses and elib functionality will be tied to a specific portage 448 New eclasses and elib functionality will be tied to a specific portage
447 version. A DEPENDs on said portage version should address this for rsync 449 version. A DEPENDs on said portage version should address this for rsync
448 users who refuse to upgrade to a portage version that supports the new 450 users who refuse to upgrade to a portage version that supports the new
449 eclasses/elibs and will gradually be unable to merge ebuilds that use said 451 eclasses/elibs and will gradually be unable to merge ebuilds that use said
450 functionality. It is their choice to upgrade, as such, the gradual 452 functionality. It is their choice to upgrade, as such, the gradual

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

  ViewVC Help
Powered by ViewVC 1.1.20