| 1 | GLEP: 33 |
1 | GLEP: 33 |
| 2 | Title: Eclass Restructure/Redesign |
2 | Title: Eclass Restructure/Redesign |
| 3 | Version: $Revision: 1.2 $ |
3 | Version: $Revision: 1.3 $ |
| 4 | Last-Modified: $Date: 2005/03/06 20:33:20 $ |
4 | Last-Modified: $Date: 2005/03/06 20:39:19 $ |
| 5 | Author: Brian Harring <ferringb@gentoo.org>, John Mylchreest <johnm@gentoo.org> |
5 | Author: Brian Harring <ferringb@gentoo.org>, John Mylchreest <johnm@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Draft |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 29-Jan-2005 |
9 | Created: 29-Jan-2005 |
| 10 | Post-History: 29-Jan-2005 |
10 | Post-History: 29-Jan-2005 6-Mar-2005 |
| 11 | |
11 | |
| 12 | |
12 | |
| 13 | Abstract |
13 | Abstract |
| 14 | ======== |
14 | ======== |
| 15 | |
15 | |
| … | |
… | |
| 126 | of elibs gives you the functionality for all phases, except for depends- depends being the |
126 | of elibs gives you the functionality for all phases, except for depends- depends being the |
| 127 | only phase that is capable of specifying metadata. Second, as an added bonus, late |
127 | only phase that is capable of specifying metadata. Second, as an added bonus, late |
| 128 | loading reduces the amount of bash sourced for a regen- faster regens. This however is minor, |
128 | loading reduces the amount of bash sourced for a regen- faster regens. This however is minor, |
| 129 | and is an ancillary benefit of the first reason. |
129 | and is an ancillary benefit of the first reason. |
| 130 | |
130 | |
| 131 | There are a few further restrictions with elibs- mainly, elibs to load can only be specified |
131 | There are a few further restrictions with elibs--mainly, elibs to load can only be specified |
| 132 | in either global scope, or in the setup, unpack, compile, test, and install phases. You can |
132 | in either global scope, or in the setup, unpack, compile, test, and install phases. You can |
| 133 | not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases, |
133 | not load elibs in prerm, postrm, preinst, and postinst. The reason being, for \*rm phases, |
| 134 | installed pkgs will have to look to the tree for the elib, which allows for api drift to cause |
134 | installed pkgs will have to look to the tree for the elib, which allows for api drift to cause |
| 135 | breakage. For *inst phases, same thing, except the culprit is binpkgs. |
135 | breakage. For \*inst phases, same thing, except the culprit is binpkgs. |
| 136 | |
136 | |
| 137 | There is a final restriction- elibs cannot change their exported api dependent on the api |
137 | There 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 |
| 139 | multiple times, as eclasses are. |
139 | multiple times, as eclasses are. |
| 140 | |
140 | |
| 141 | To clarify, for example this is invalid. |
141 | To 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 |
| … | |
… | |
| 441 | a more in depth discussion of the issue, along with a more extensive explanation |
442 | a more in depth discussion of the issue, along with a more extensive explanation |
| 442 | of the potential solutions, and reasons for the chosen solution. |
443 | of the potential solutions, and reasons for the chosen solution. |
| 443 | |
444 | |
| 444 | To recap: |
445 | To 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 |