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

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

Parent Directory | Revision Log | View Patch Patch

Revision 1.3		Revision 1.5
…		…
6	PEP, see http://www.python.org/peps/pep-0001.html for instructions and links	6	PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
7	to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!	7	to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
8	-->	8	-->
9	<head>	9	<head>
10	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />	10	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
11	<meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />	11	<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
12	<title>GLEP 33 -- Eclass Restructure/Redesign</title>	12	<title>GLEP 33 -- Eclass Restructure/Redesign</title>
13	<link rel="stylesheet" href="tools/glep.css" type="text/css" />	13	<style type="text/css">
		14
		15	/*
		16	:Author: David Goodger
		17	:Contact: goodger@users.sourceforge.net
		18	:date: $Date: 2006/09/05 20:55:13 $
		19	:version: $Revision: 1.5 $
		20	:copyright: This stylesheet has been placed in the public domain.
		21
		22	Default cascading style sheet for the PEP HTML output of Docutils.
		23	*/
		24
		25	.first {
		26	margin-top: 0 }
		27
		28	.last {
		29	margin-bottom: 0 }
		30
		31	.navigation {
		32	width: 100% ;
		33	background: #cc99ff ;
		34	margin-top: 0px ;
		35	margin-bottom: 0px }
		36
		37	.navigation .navicon {
		38	width: 150px ;
		39	height: 35px }
		40
		41	.navigation .textlinks {
		42	padding-left: 1em ;
		43	text-align: left }
		44
		45	.navigation td, .navigation th {
		46	padding-left: 0em ;
		47	padding-right: 0em ;
		48	vertical-align: middle }
		49
		50	.rfc2822 {
		51	margin-top: 0.5em ;
		52	margin-left: 0.5em ;
		53	margin-right: 0.5em ;
		54	margin-bottom: 0em }
		55
		56	.rfc2822 td {
		57	text-align: left }
		58
		59	.rfc2822 th.field-name {
		60	text-align: right ;
		61	font-family: sans-serif ;
		62	padding-right: 0.5em ;
		63	font-weight: bold ;
		64	margin-bottom: 0em }
		65
		66	a.toc-backref {
		67	text-decoration: none ;
		68	color: black }
		69
		70	body {
		71	margin: 0px ;
		72	margin-bottom: 1em ;
		73	padding: 0px }
		74
		75	dd {
		76	margin-bottom: 0.5em }
		77
		78	div.section {
		79	margin-left: 1em ;
		80	margin-right: 1em ;
		81	margin-bottom: 1.5em }
		82
		83	div.section div.section {
		84	margin-left: 0em ;
		85	margin-right: 0em ;
		86	margin-top: 1.5em }
		87
		88	div.abstract {
		89	margin: 2em 5em }
		90
		91	div.abstract p.topic-title {
		92	font-weight: bold ;
		93	text-align: center }
		94
		95	div.attention, div.caution, div.danger, div.error, div.hint,
		96	div.important, div.note, div.tip, div.warning {
		97	margin: 2em ;
		98	border: medium outset ;
		99	padding: 1em }
		100
		101	div.attention p.admonition-title, div.caution p.admonition-title,
		102	div.danger p.admonition-title, div.error p.admonition-title,
		103	div.warning p.admonition-title {
		104	color: red ;
		105	font-weight: bold ;
		106	font-family: sans-serif }
		107
		108	div.hint p.admonition-title, div.important p.admonition-title,
		109	div.note p.admonition-title, div.tip p.admonition-title {
		110	font-weight: bold ;
		111	font-family: sans-serif }
		112
		113	div.figure {
		114	margin-left: 2em }
		115
		116	div.footer, div.header {
		117	font-size: smaller }
		118
		119	div.footer {
		120	margin-left: 1em ;
		121	margin-right: 1em }
		122
		123	div.system-messages {
		124	margin: 5em }
		125
		126	div.system-messages h1 {
		127	color: red }
		128
		129	div.system-message {
		130	border: medium outset ;
		131	padding: 1em }
		132
		133	div.system-message p.system-message-title {
		134	color: red ;
		135	font-weight: bold }
		136
		137	div.topic {
		138	margin: 2em }
		139
		140	h1 {
		141	font-family: sans-serif ;
		142	font-size: large }
		143
		144	h2 {
		145	font-family: sans-serif ;
		146	font-size: medium }
		147
		148	h3 {
		149	font-family: sans-serif ;
		150	font-size: small }
		151
		152	h4 {
		153	font-family: sans-serif ;
		154	font-style: italic ;
		155	font-size: small }
		156
		157	h5 {
		158	font-family: sans-serif;
		159	font-size: x-small }
		160
		161	h6 {
		162	font-family: sans-serif;
		163	font-style: italic ;
		164	font-size: x-small }
		165
		166	.section hr {
		167	width: 75% }
		168
		169	ol.simple, ul.simple {
		170	margin-bottom: 1em }
		171
		172	ol.arabic {
		173	list-style: decimal }
		174
		175	ol.loweralpha {
		176	list-style: lower-alpha }
		177
		178	ol.upperalpha {
		179	list-style: upper-alpha }
		180
		181	ol.lowerroman {
		182	list-style: lower-roman }
		183
		184	ol.upperroman {
		185	list-style: upper-roman }
		186
		187	p.caption {
		188	font-style: italic }
		189
		190	p.credits {
		191	font-style: italic ;
		192	font-size: smaller }
		193
		194	p.label {
		195	white-space: nowrap }
		196
		197	p.topic-title {
		198	font-family: sans-serif ;
		199	font-weight: bold }
		200
		201	pre.line-block {
		202	font-family: serif ;
		203	font-size: 100% }
		204
		205	pre.literal-block, pre.doctest-block {
		206	margin-left: 2em ;
		207	margin-right: 2em ;
		208	background-color: #eeeeee }
		209
		210	span.classifier {
		211	font-family: sans-serif ;
		212	font-style: oblique }
		213
		214	span.classifier-delimiter {
		215	font-family: sans-serif ;
		216	font-weight: bold }
		217
		218	span.interpreted {
		219	font-family: sans-serif }
		220
		221	span.option-argument {
		222	font-style: italic }
		223
		224	span.pre {
		225	white-space: pre }
		226
		227	span.problematic {
		228	color: red }
		229
		230	table {
		231	margin-top: 0.5em ;
		232	margin-bottom: 0.5em }
		233
		234	td, th {
		235	padding-left: 0.5em ;
		236	padding-right: 0.5em ;
		237	vertical-align: top }
		238
		239	td.num {
		240	text-align: right }
		241
		242	th.field-name {
		243	font-weight: bold ;
		244	text-align: left ;
		245	white-space: nowrap }
		246
		247	h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
		248	font-size: 100% }
		249
		250	tt {
		251	background-color: #eeeeee }
		252
		253	ul.auto-toc {
		254	list-style-type: none }
		255
		256	</style>
14	</head>	257	</head>
15	<body bgcolor="white">	258	<body bgcolor="white">
16	<table class="navigation" cellpadding="0" cellspacing="0"	259	<table class="navigation" cellpadding="0" cellspacing="0"
17	width="100%" border="0">	260	width="100%" border="0">
18	<tr><td class="navicon" width="150" height="35">	261	<tr><td class="navicon" width="150" height="35">
19	<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">	262	<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
20	<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"	263	<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
21	border="0" width="150" height="35" /></a></td>	264	border="0" width="150" height="35" /></a></td>
22	<td class="textlinks" align="left">	265	<td class="textlinks" align="left">
23	[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]	266	[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
24	[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]	267	[<b><a href="http://www.gentoo.org/peps">GLEP Index</a></b>]
25	[<b><a href="./glep-0033.txt">GLEP Source</a></b>]	268	[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0033.txt">GLEP Source</a></b>]
26	</td></tr></table>	269	</td></tr></table>
27	<table class="rfc2822 docutils field-list" frame="void" rules="none">	270	<table class="rfc2822 docutils field-list" frame="void" rules="none">
28	<col class="field-name" />	271	<col class="field-name" />
29	<col class="field-body" />	272	<col class="field-body" />
30	<tbody valign="top">	273	<tbody valign="top">
31	<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td>	274	<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td>
32	</tr>	275	</tr>
33	<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td>	276	<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td>
34	</tr>	277	</tr>
35	<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>	278	<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
36	</tr>	279	</tr>
37	<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2005/03/06 20:39:19</a></td>	280	<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td>
38	</tr>	281	</tr>
39	<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring <ferringb at gentoo.org>, John Mylchreest <johnm at gentoo.org></td>	282	<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring <ferringb at gentoo.org>, John Mylchreest <johnm at gentoo.org></td>
40	</tr>	283	</tr>
41	<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>	284	<tr class="field"><th class="field-name">Status:</th><td class="field-body">Moribund</td>
42	</tr>	285	</tr>
43	<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>	286	<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
44	</tr>	287	</tr>
45	<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="http://www.python.org/peps/glep-0012.html">text/x-rst</a></td>	288	<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
46	</tr>	289	</tr>
47	<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td>	290	<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td>
48	</tr>	291	</tr>
49	<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005</td>	292	<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006</td>
50	</tr>	293	</tr>
51	</tbody>	294	</tbody>
52	</table>	295	</table>
53	<hr />	296	<hr />
54	<div class="contents topic" id="contents">	297	<div class="contents topic">
55	<p class="topic-title first"><a name="contents">Contents</a></p>	298	<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
56	<ul class="simple">	299	<ul class="simple">
		300	<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
57	<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li>	301	<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
58	<li><a class="reference" href="#terminology" id="id3" name="id3">Terminology</a></li>	302	<li><a class="reference" href="#terminology" id="id4" name="id4">Terminology</a></li>
59	<li><a class="reference" href="#motivation-and-rationale" id="id4" name="id4">Motivation and Rationale</a></li>	303	<li><a class="reference" href="#motivation-and-rationale" id="id5" name="id5">Motivation and Rationale</a></li>
60	<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a><ul>	304	<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
61	<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id6" name="id6">Ebuild Libraries (elibs for short)</a></li>	305	<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id7" name="id7">Ebuild Libraries (elibs for short)</a></li>
62	<li><a class="reference" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id7" name="id7">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li>	306	<li><a class="reference" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id8" name="id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li>
63	<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id8" name="id8">The end of backwards compatibility...</a></li>	307	<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id9" name="id9">The end of backwards compatibility...</a></li>
64	<li><a class="reference" href="#tree-restructuring" id="id9" name="id9">Tree restructuring</a></li>	308	<li><a class="reference" href="#tree-restructuring" id="id10" name="id10">Tree restructuring</a></li>
65	<li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id10" name="id10">The start of a different phase of backwards compatibility</a></li>	309	<li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id11" name="id11">The start of a different phase of backwards compatibility</a></li>
66	<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li>	310	<li><a class="reference" href="#migrating-to-the-new-setup" id="id12" name="id12">Migrating to the new setup</a></li>
67	</ul>	311	</ul>
68	</li>	312	</li>
69	<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li>	313	<li><a class="reference" href="#backwards-compatibility" id="id13" name="id13">Backwards Compatibility</a></li>
70	<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>	314	<li><a class="reference" href="#copyright" id="id14" name="id14">Copyright</a></li>
71	</ul>	315	</ul>
72	</div>	316	</div>
73	<div class="section" id="abstract">	317	<div class="section">
		318	<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
		319	<p>Approved by the Gentoo Council on 15 September 2005. As of Sept. 2006
		320	this GLEP is on hold, pending future revisions.</p>
		321	</div>
		322	<div class="section">
74	<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1>	323	<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
75	<p>For any design, the transition from theoretical to applied exposes inadequacies	324	<p>For any design, the transition from theoretical to applied exposes inadequacies
76	in the original design. This document is intended to document, and propose a	325	in the original design. This document is intended to document, and propose a
77	revision of the current eclass setup to address current eclass inadequacies.</p>	326	revision of the current eclass setup to address current eclass inadequacies.</p>
78	<p>This document proposes several things- the creation of ebuild libraries, 'elibs',	327	<p>This document proposes several things- the creation of ebuild libraries, 'elibs',
79	a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the	328	a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the
80	addition of changelogs, and a way to allow for simple eclass gpg signing.	329	addition of changelogs, and a way to allow for simple eclass gpg signing.
81	In general, a large scale restructuring of what eclasses are and how they're	330	In general, a large scale restructuring of what eclasses are and how they're
82	implemented. Essentially version two of the eclass setup.</p>	331	implemented. Essentially version two of the eclass setup.</p>
83	</div>	332	</div>
84	<div class="section" id="terminology">	333	<div class="section">
85	<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1>	334	<h1><a class="toc-backref" href="#id4" id="terminology" name="terminology">Terminology</a></h1>
86	<p>From this point on, the proposed eclass setup will be called 'new eclasses', the	335	<p>From this point on, the proposed eclass setup will be called 'new eclasses', the
87	existing crop (as of this writing) will be referenced as 'old eclasses'. The	336	existing crop (as of this writing) will be referenced as 'old eclasses'. The
88	distinction is elaborated on within this document.</p>	337	distinction is elaborated on within this document.</p>
89	</div>	338	</div>
90	<div class="section" id="motivation-and-rationale">	339	<div class="section">
91	<h1><a class="toc-backref" href="#id4" name="motivation-and-rationale">Motivation and Rationale</a></h1>	340	<h1><a class="toc-backref" href="#id5" id="motivation-and-rationale" name="motivation-and-rationale">Motivation and Rationale</a></h1>
92	<p>Eclasses within the tree currently are a bit of a mess- they're forced to	341	<p>Eclasses within the tree currently are a bit of a mess- they're forced to
93	maintain backwards compatibility w/ all previous functionality. In effect,	342	maintain backwards compatibility w/ all previous functionality. In effect,
94	their api is constant, and can only be added to- never changing the existing	343	their api is constant, and can only be added to- never changing the existing
95	functionality. This obviously is quite limiting, and leads to cruft accruing in	344	functionality. This obviously is quite limiting, and leads to cruft accruing in
96	eclasses as a eclasses design is refined. This needs to be dealt with prior to	345	eclasses as a eclasses design is refined. This needs to be dealt with prior to
…		…
107	function they're using, but shouldn't have to worry about their default src_*	356	function they're using, but shouldn't have to worry about their default src_*
108	and pkg_* functions being overwritten, let alone the env changes.</p>	357	and pkg_* functions being overwritten, let alone the env changes.</p>
109	<p>Addressing up front why a collection of eclass refinements are being rolled into	358	<p>Addressing up front why a collection of eclass refinements are being rolled into
110	a single set of changes, parts of this proposal -could- be split into multiple	359	a single set of changes, parts of this proposal -could- be split into multiple
111	phases. Why do it though? It's simpler for developers to know that the first	360	phases. Why do it though? It's simpler for developers to know that the first
112	eclass specification was this, and that the second specification is that,	361	eclass specification was this, and that the second specification is that,
113	rather then requiring them to be aware of what phase of eclass changes is in	362	rather then requiring them to be aware of what phase of eclass changes is in
114	progress.</p>	363	progress.</p>
115	<p>By rolling all changes into one large change, a line is intentionally drawn in	364	<p>By rolling all changes into one large change, a line is intentionally drawn in
116	the sand. Old eclasses allowed for this, behaved this way. New eclasses allow	365	the sand. Old eclasses allowed for this, behaved this way. New eclasses allow
117	for that, and behave this way. This should reduce misconceptions about what is	366	for that, and behave this way. This should reduce misconceptions about what is
118	allowed/possible with eclasses, thus reducing bugs that result from said	367	allowed/possible with eclasses, thus reducing bugs that result from said
119	misconceptions.</p>	368	misconceptions.</p>
120	<p>A few words on elibs- think of them as a clear definition between behavioral	369	<p>A few words on elibs- think of them as a clear definition between behavioral
121	functionality of an eclass, and the library functionality. Eclass's modify	370	functionality of an eclass, and the library functionality. Eclass's modify
122	template data, and are the basis for other ebuilds- elibs, however are <em>just</em>	371	template data, and are the basis for other ebuilds- elibs, however are <em>just</em>
123	common bash functionality.</p>	372	common bash functionality.</p>
124	<p>Consider the majority of the portage bin/* scripts- these all are candidates for	373	<p>Consider the majority of the portage bin/* scripts- these all are candidates for
125	being added to the tree as elibs, as is the bulk of eutils.</p>	374	being added to the tree as elibs, as is the bulk of eutils.</p>
126	</div>	375	</div>
127	<div class="section" id="specification">	376	<div class="section">
128	<h1><a class="toc-backref" href="#id5" name="specification">Specification</a></h1>	377	<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
129	<p>The various parts of this proposal are broken down into a set of changes and	378	<p>The various parts of this proposal are broken down into a set of changes and
130	elaborations on why a proposed change is preferable. It's advisable to the	379	elaborations on why a proposed change is preferable. It's advisable to the
131	reader that this be read serially, rather then jumping around.</p>	380	reader that this be read serially, rather then jumping around.</p>
132	<div class="section" id="ebuild-libraries-elibs-for-short">	381	<div class="section">
133	<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>	382	<h2><a class="toc-backref" href="#id7" id="ebuild-libraries-elibs-for-short" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>
134	<p>As briefly touched upon in Motivation and Rationale, the original eclass design	383	<p>As briefly touched upon in Motivation and Rationale, the original eclass design
135	allowed for the eclass to modify the metadata of an ebuild, metadata being the	384	allowed for the eclass to modify the metadata of an ebuild, metadata being the
136	DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,	385	DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,
137	and used by portage for dep resolution, fetching, etc. Using the earlier	386	and used by portage for dep resolution, fetching, etc. Using the earlier
138	example, if you're after a single function from an eclass (say epatch from	387	example, if you're after a single function from an eclass (say epatch from
…		…
140	inheriting might do. You want to treat the eclass you're pulling from as a	389	inheriting might do. You want to treat the eclass you're pulling from as a
141	library, pure and simple.</p>	390	library, pure and simple.</p>
142	<p>A new directory named elib should be added to the top level of the tree to serve	391	<p>A new directory named elib should be added to the top level of the tree to serve
143	as a repository of ebuild function libraries. Rather then relying on using the	392	as a repository of ebuild function libraries. Rather then relying on using the
144	source command, an 'elib' function should be added to portage to import that	393	source command, an 'elib' function should be added to portage to import that
145	libraries functionality. The reason for the indirection via the function is	394	libraries functionality. The reason for the indirection via the function is
146	mostly related to portage internals, but it does serve as an abstraction such	395	mostly related to portage internals, but it does serve as an abstraction such
147	that (for example) zsh compatibility hacks could be hidden in the elib function.</p>	396	that (for example) zsh compatibility hacks could be hidden in the elib function.</p>
148	<p>Elib's will be collections of bash functions- they're not allowed to do anything	397	<p>Elib's will be collections of bash functions- they're not allowed to do anything
149	in the global scope aside from function definition, and any -minimal-	398	in the global scope aside from function definition, and any -minimal-
150	initialization of the library that is absolutely needed. Additionally, they	399	initialization of the library that is absolutely needed. Additionally, they
151	cannot modify any ebuild template functions- src_compile, src_unpack. Since they are	400	cannot modify any ebuild template functions- src_compile, src_unpack. Since they are
152	required to not modify the metadata keys, nor in any way affect the ebuild aside	401	required to not modify the metadata keys, nor in any way affect the ebuild aside
153	from providing functionality, they can be conditionally pulled in. They also	402	from providing functionality, they can be conditionally pulled in. They also
154	are allowed to pull in other elibs, but strictly just elibs- no eclasses, just	403	are allowed to pull in other elibs, but strictly just elibs- no eclasses, just
155	other elibs. A real world example would be the eutils eclass.</p>	404	other elibs. A real world example would be the eutils eclass.</p>
156	<p>Portage, since the elib's don't modify metadata, isn't required to track elibs	405	<p>Portage, since the elib's don't modify metadata, isn't required to track elibs
157	as it tracks eclasses. Thus a change in an elib doesn't result in half the tree	406	as it tracks eclasses. Thus a change in an elib doesn't result in half the tree
158	forced to be regenerated/marked stale when changed (this is more of an infra	407	forced to be regenerated/marked stale when changed (this is more of an infra
159	benefit, although regen's that take too long due to eclass changes have been	408	benefit, although regen's that take too long due to eclass changes have been
160	known to cause rsync issues due to missing timestamps).</p>	409	known to cause rsync issues due to missing timestamps).</p>
161	<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the	410	<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the
162	depends phase (basically a phase that sources the ebuild, to get its metadata). Elib	411	depends phase (basically a phase that sources the ebuild, to get its metadata). Elib
163	calls in the global scope will be tracked, but the elib will not be loaded till just before	412	calls in the global scope will be tracked, but the elib will not be loaded till just before
164	the setup phase (pkg_setup). There are two reasons for this- first, it ensures elibs are	413	the setup phase (pkg_setup). There are two reasons for this- first, it ensures elibs are
165	completely incapable of modifying metadata. There is no room for confusion, late loading	414	completely incapable of modifying metadata. There is no room for confusion, late loading
166	of elibs gives you the functionality for all phases, except for depends- depends being the	415	of elibs gives you the functionality for all phases, except for depends- depends being the
167	only phase that is capable of specifying metadata. Second, as an added bonus, late	416	only phase that is capable of specifying metadata. Second, as an added bonus, late
168	loading reduces the amount of bash sourced for a regen- faster regens. This however is minor,	417	loading reduces the amount of bash sourced for a regen- faster regens. This however is minor,
169	and is an ancillary benefit of the first reason.</p>	418	and is an ancillary benefit of the first reason.</p>
170	<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified	419	<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified
171	in either global scope, or in the setup, unpack, compile, test, and install phases. You can	420	in either global scope, or in the setup, unpack, compile, test, and install phases. You can
172	not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases,	421	not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases,
173	installed pkgs will have to look to the tree for the elib, which allows for api drift to cause	422	installed pkgs will have to look to the tree for the elib, which allows for api drift to cause
174	breakage. For *inst phases, same thing, except the culprit is binpkgs.</p>	423	breakage. For *inst phases, same thing, except the culprit is binpkgs.</p>
175	<p>There is a final restriction--elibs cannot change their exported api dependent on the api	424	<p>There is a final restriction--elibs cannot change their exported api dependent on the api
176	(as some eclass do for example). The reason mainly being that elibs are loaded once--not	425	(as some eclass do for example). The reason mainly being that elibs are loaded once--not
177	multiple times, as eclasses are.</p>	426	multiple times, as eclasses are.</p>
178	<p>To clarify, for example this is invalid.</p>	427	<p>To clarify, for example this is invalid.</p>
179	<pre class="literal-block">	428	<pre class="literal-block">
180	if [[ -n ${SOME_VAR} ]]; then	429	if [[ -n ${SOME_VAR} ]]; then
181	func x() { echo "I'm accessible only via tweaking some var";}	430	func x() { echo "I'm accessible only via tweaking some var";}
…		…
192	<p>There is no need for backwards compatibility with elibs- they just must work	441	<p>There is no need for backwards compatibility with elibs- they just must work
193	against the current tree. Thus elibs can be removed when the tree no longer	442	against the current tree. Thus elibs can be removed when the tree no longer
194	needs them. The reasons for this are explained below.</p>	443	needs them. The reasons for this are explained below.</p>
195	<p>Structuring of the elibs directory will be exactly the same as that of the new	444	<p>Structuring of the elibs directory will be exactly the same as that of the new
196	eclass directory (detailed below), sans a different extension.</p>	445	eclass directory (detailed below), sans a different extension.</p>
197	<p>As to why their are so many restrictions, the answer is simple- the definition of	446	<p>As to why their are so many restrictions, the answer is simple- the definition of
198	what elibs are, what they are capable of, and how to use them is nailed down as much as	447	what elibs are, what they are capable of, and how to use them is nailed down as much as
199	possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear,	448	possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear,
200	such that no misconceptions occur, resulting in bugs.</p>	449	such that no misconceptions occur, resulting in bugs.</p>
201	</div>	450	</div>
202	<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">	451	<div class="section">
203	<h2><a class="toc-backref" href="#id7" name="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2>	452	<h2><a class="toc-backref" href="#id8" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" name="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2>
204	<p>Since elibs are now intended on holding common bash functionality, the focus of	453	<p>Since elibs are now intended on holding common bash functionality, the focus of
205	eclasses should be in defining an appropriate template for ebuilds. For example,	454	eclasses should be in defining an appropriate template for ebuilds. For example,
206	defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.	455	defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
207	Additionally, eclasses should pull in any elibs they need for functionality.</p>	456	Additionally, eclasses should pull in any elibs they need for functionality.</p>
208	<p>Eclass functionality that isn't directly related to the metadata, or src_* and	457	<p>Eclass functionality that isn't directly related to the metadata, or src_* and
…		…
221	pulled in, leading to compilation failure, or dud deps.</p>	470	pulled in, leading to compilation failure, or dud deps.</p>
222	<p>If the existing metadata isn't flexible enough for what is required for a	471	<p>If the existing metadata isn't flexible enough for what is required for a
223	package, the parsing of the metadata is changed to address that. Cases where	472	package, the parsing of the metadata is changed to address that. Cases where
224	the constant requirement is violated are known, and a select few are allowed-	473	the constant requirement is violated are known, and a select few are allowed-
225	these are exceptions to the rule that are required due to inadequacies in	474	these are exceptions to the rule that are required due to inadequacies in
226	portage. Any case where it's determined the constant requirement may need to be	475	portage. Any case where it's determined the constant requirement may need to be
227	violated the dev must make it aware to the majority of devs, along with the portage	476	violated the dev must make it aware to the majority of devs, along with the portage
228	devs. This should be done prior to committing.</p>	477	devs. This should be done prior to committing.</p>
229	<p>It's quite likely there is a way to allow what you're attempting- if you just go	478	<p>It's quite likely there is a way to allow what you're attempting- if you just go
230	and do it, the rsync users (our user base) suffer the results of compilation	479	and do it, the rsync users (our user base) suffer the results of compilation
231	failures and unneeded deps being pulled in.</p>	480	failures and unneeded deps being pulled in.</p>
232	<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS	481	<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS
…		…
236	indefinitely- compatibility must be maintained against the current tree, but	485	indefinitely- compatibility must be maintained against the current tree, but
237	just that. As such new eclasses (the true distinction of new vs old is	486	just that. As such new eclasses (the true distinction of new vs old is
238	elaborated in the next section) can be removed from the tree once they're no	487	elaborated in the next section) can be removed from the tree once they're no
239	longer in use.</p>	488	longer in use.</p>
240	</div>	489	</div>
241	<div class="section" id="the-end-of-backwards-compatibility">	490	<div class="section">
242	<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2>	491	<h2><a class="toc-backref" href="#id9" id="the-end-of-backwards-compatibility" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2>
243	<p>With current eclasses, once the eclass is in use, its api can no longer be	492	<p>With current eclasses, once the eclass is in use, its api can no longer be
244	changed, nor can the eclass ever be removed from the tree. This is why we still	493	changed, nor can the eclass ever be removed from the tree. This is why we still
245	have <em>ancient</em> eclasses that are completely unused sitting in the tree, for	494	have <em>ancient</em> eclasses that are completely unused sitting in the tree, for
246	example inherit.eclass. The reason for this, not surprisingly, is a portage	495	example inherit.eclass. The reason for this, not surprisingly, is a portage
247	deficiency: on unmerging an installed ebuild, portage used the eclass from the	496	deficiency: on unmerging an installed ebuild, portage used the eclass from the
248	current tree.</p>	497	current tree.</p>
249	<p>For a real world example of this, if you merged a glibc 2 years back, whatever	498	<p>For a real world example of this, if you merged a glibc 2 years back, whatever
250	eclasses it used must still be compatible, or you may not be able to unmerge the	499	eclasses it used must still be compatible, or you may not be able to unmerge the
251	older glibc version during an upgrade to a newer version. So either the glibc	500	older glibc version during an upgrade to a newer version. So either the glibc
…		…
260	be re-used rather then relying on the eclass. In other words, binpkgs and	509	be re-used rather then relying on the eclass. In other words, binpkgs and
261	installed ebuilds will no longer go and pull needed eclasses from the tree,	510	installed ebuilds will no longer go and pull needed eclasses from the tree,
262	they'll use the 'saved' version of the eclass they were built/merged with.</p>	511	they'll use the 'saved' version of the eclass they were built/merged with.</p>
263	<p>So the backwards compatibility requirement for users of the next major portage	512	<p>So the backwards compatibility requirement for users of the next major portage
264	version (and beyond) isn't required. All the cruft can be dropped.</p>	513	version (and beyond) isn't required. All the cruft can be dropped.</p>
265	<p>The problem is that there will be users using older versions of portage that don't	514	<p>The problem is that there will be users using older versions of portage that don't
266	support this functionality- these older installations <em>cannot</em> use the	515	support this functionality- these older installations <em>cannot</em> use the
267	new eclasses, due to the fact that their portage version is incapable of	516	new eclasses, due to the fact that their portage version is incapable of
268	properly relying on the env- in other words, the varying api of the eclass will	517	properly relying on the env- in other words, the varying api of the eclass will
269	result in user-visible failures during unmerging.</p>	518	result in user-visible failures during unmerging.</p>
270	<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need	519	<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need
271	a means to basically disallow access to the new eclasses for all portage versions	520	a means to basically disallow access to the new eclasses for all portage versions
272	incapable of properly handling the env requirements.</p>	521	incapable of properly handling the env requirements.</p>
273	<p>Unfortunately, we cannot just rely on a different grouping/naming convention within	522	<p>Unfortunately, we cannot just rely on a different grouping/naming convention within
274	the old eclass directory. The new eclasses must be inaccessible, and portage throws	523	the old eclass directory. The new eclasses must be inaccessible, and portage throws
275	a snag into this- the existing inherit function that is used to handle existing	524	a snag into this- the existing inherit function that is used to handle existing
276	eclasses. Basically, whatever it's passed (inherit kernel or inherit	525	eclasses. Basically, whatever it's passed (inherit kernel or inherit
277	kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass	526	kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass
278	respectively). So even if the new eclasses were implemented within a	527	respectively). So even if the new eclasses were implemented within a
279	subdirectory of the eclass dir in the tree, all current portage versions would	528	subdirectory of the eclass dir in the tree, all current portage versions would
280	still be able to access them.</p>	529	still be able to access them.</p>
281	<p>In other words, these new eclasses would in effect, be old eclasses since older	530	<p>In other words, these new eclasses would in effect, be old eclasses since older
282	portage versions could still access them.</p>	531	portage versions could still access them.</p>
283	</div>	532	</div>
284	<div class="section" id="tree-restructuring">	533	<div class="section">
285	<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring</a></h2>	534	<h2><a class="toc-backref" href="#id10" id="tree-restructuring" name="tree-restructuring">Tree restructuring</a></h2>
286	<p>There are only two way to block the existing (as of this writing) inherit	535	<p>There are only two way to block the existing (as of this writing) inherit
287	functionality from accessing the new eclasses- either change the extension of	536	functionality from accessing the new eclasses- either change the extension of
288	eclasses to something other then 'eclass', or to have them stored in a separate	537	eclasses to something other then 'eclass', or to have them stored in a separate
289	subdirectory of the tree then eclass.</p>	538	subdirectory of the tree then eclass.</p>
290	<p>The latter is preferable, and the proposed solution. Reasons are- the current	539	<p>The latter is preferable, and the proposed solution. Reasons are- the current
291	eclass directory is already overgrown. Structuring of the new eclass dir	540	eclass directory is already overgrown. Structuring of the new eclass dir
292	(clarified below) will allow for easier signing, ChangeLogs, and grouping of	541	(clarified below) will allow for easier signing, ChangeLogs, and grouping of
293	eclasses. New eclasses allow for something akin to a clean break and have new	542	eclasses. New eclasses allow for something akin to a clean break and have new
294	capabilities/requirements, thus it's advisable to start with a clean directory,	543	capabilities/requirements, thus it's advisable to start with a clean directory,
295	devoid of all cruft from the old eclass implementation.</p>	544	devoid of all cruft from the old eclass implementation.</p>
296	<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new	545	<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new
297	eclasses, please reread the previous section. It's unfortunately a requirement	546	eclasses, please reread the previous section. It's unfortunately a requirement
298	to take advantage of all that the next major portage release will allow.</p>	547	to take advantage of all that the next major portage release will allow.</p>
299	<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.	548	<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
…		…
323	to ensure no files are missing, and that nothing has been tainted.</p>	572	to ensure no files are missing, and that nothing has been tainted.</p>
324	<p>The elib directory will be structured in the same way, for the same reasons.</p>	573	<p>The elib directory will be structured in the same way, for the same reasons.</p>
325	<p>Repoman will have to be extended to work within new eclass and elib groups, and	574	<p>Repoman will have to be extended to work within new eclass and elib groups, and
326	to handle signing and committing. This is intentional, and a good thing. This	575	to handle signing and committing. This is intentional, and a good thing. This
327	gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p>	576	gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p>
328	<p>Note these checks will not prevent developers from doing dumb things with eclass-	577	<p>Note these checks will not prevent developers from doing dumb things with eclass-
329	these checks would only be capable of doing basic sanity checks, such as syntax checks.	578	these checks would only be capable of doing basic sanity checks, such as syntax checks.
330	There is no way to prevent people from doing dumb things (exempting perhaps repeated	579	There is no way to prevent people from doing dumb things (exempting perhaps repeated
331	applications of a cattle prod)- these are strictly automatic checks, akin to repoman's	580	applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
332	dependency checks.</p>	581	dependency checks.</p>
333	</div>	582	</div>
334	<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility">	583	<div class="section">
335	<h2><a class="toc-backref" href="#id10" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2>	584	<h2><a class="toc-backref" href="#id11" id="the-start-of-a-different-phase-of-backwards-compatibility" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2>
336	<p>As clarified above, new eclasses will exist in a separate directory that will be	585	<p>As clarified above, new eclasses will exist in a separate directory that will be
337	intentionally inaccessible to the inherit function. As such, users of older	586	intentionally inaccessible to the inherit function. As such, users of older
338	portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new	587	portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new
339	eclasses. A depend on the next major portage version would transparently handle	588	eclasses. A depend on the next major portage version would transparently handle
340	this for rsync users.</p>	589	this for rsync users.</p>
341	<p>There still is the issue of users who haven't upgraded to the required portage	590	<p>There still is the issue of users who haven't upgraded to the required portage
342	version. This is a minor concern frankly- portage releases include new	591	version. This is a minor concern frankly- portage releases include new
343	functionality, and bug fixes. If they won't upgrade, it's assumed they have	592	functionality, and bug fixes. If they won't upgrade, it's assumed they have
344	their reasons and are big boys, thus able to handle the complications themselves.</p>	593	their reasons and are big boys, thus able to handle the complications themselves.</p>
…		…
358	<p>For users who do not upgrade within the window of N months while the old	607	<p>For users who do not upgrade within the window of N months while the old
359	eclasses are in the tree, as stated, it's assumed they know what they are doing.	608	eclasses are in the tree, as stated, it's assumed they know what they are doing.
360	If they specifically block the new portage version, as the ebuilds in the tree	609	If they specifically block the new portage version, as the ebuilds in the tree
361	migrate to the new eclasses, they will have less and less ebuilds available to	610	migrate to the new eclasses, they will have less and less ebuilds available to
362	them. If they tried injecting the new portage version (lying to portage,	611	them. If they tried injecting the new portage version (lying to portage,
363	essentially), portage would bail since it cannot find the new eclass.	612	essentially), portage would bail since it cannot find the new eclass.
364	For ebuilds that use the new eclasses, there really isn't any way to sidestep	613	For ebuilds that use the new eclasses, there really isn't any way to sidestep
365	the portage version requirement- same as it has been for other portage features.</p>	614	the portage version requirement- same as it has been for other portage features.</p>
366	<p>What is a bit more annoying is that once the old eclasses are out of the tree,	615	<p>What is a bit more annoying is that once the old eclasses are out of the tree,
367	if a user has not upgraded to a portage version supporting env processing, they	616	if a user has not upgraded to a portage version supporting env processing, they
368	will lose the ability to unmerge any installed ebuild that used an old	617	will lose the ability to unmerge any installed ebuild that used an old
369	eclass. Same cause, different symptom being they will lose the ability to merge	618	eclass. Same cause, different symptom being they will lose the ability to merge
370	any tbz2 that uses old eclasses also.</p>	619	any tbz2 that uses old eclasses also.</p>
371	<p>There is one additional case that is a rarity, but should be noted- if a user	620	<p>There is one additional case that is a rarity, but should be noted- if a user
372	has suffered significant corruption of their installed package database (vdb). This is	621	has suffered significant corruption of their installed package database (vdb). This is
373	ignoring the question of whether the vdb is even usable at this point, but the possibility	622	ignoring the question of whether the vdb is even usable at this point, but the possibility
374	exists for the saved envs to be non usable due to either A) missing, or B) corrupted.	623	exists for the saved envs to be non usable due to either A) missing, or B) corrupted.
375	In such a case, even with the new portage capabilities, they would need	624	In such a case, even with the new portage capabilities, they would need
376	the old eclass compat ebuild.</p>	625	the old eclass compat ebuild.</p>
377	<p>Note for this to happen requires either rather... unwise uses of root, or significant	626	<p>Note for this to happen requires either rather... unwise uses of root, or significant
378	fs corruption. Regardless of the cause, it's quite likely for this to even become an	627	fs corruption. Regardless of the cause, it's quite likely for this to even become an
379	issue, the system's vdb is completely unusable. It's a moot issue at that point.	628	issue, the system's vdb is completely unusable. It's a moot issue at that point.
380	If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage-	629	If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage-
381	it doesn't know what's installed, it doesn't know of its own files, and in general,	630	it doesn't know what's installed, it doesn't know of its own files, and in general,
382	a rebuilding of the system is about the only sane course of action. The missing env is	631	a rebuilding of the system is about the only sane course of action. The missing env is
383	truly the least of the users concern in such a case.</p>	632	truly the least of the users concern in such a case.</p>
384	<p>Continuing with the more likely scenario, users unwilling to upgrade portage will	633	<p>Continuing with the more likely scenario, users unwilling to upgrade portage will
385	<em>not</em> be left out in the rain. Merging the old eclass compat ebuild will provide	634	<em>not</em> be left out in the rain. Merging the old eclass compat ebuild will provide
386	the missing eclasses, thus providing that lost functionality.</p>	635	the missing eclasses, thus providing that lost functionality.</p>
387	<p>Note the intention isn't to force them to upgrade, hence the ability to restore the	636	<p>Note the intention isn't to force them to upgrade, hence the ability to restore the
388	lost functionality. The intention is to clean up the existing mess, and allow us	637	lost functionality. The intention is to clean up the existing mess, and allow us
389	to move forward. The saying "you've got to break a few eggs to make an omelet"	638	to move forward. The saying "you've got to break a few eggs to make an omelet"
390	is akin, exempting the fact we're providing a way to make the eggs whole again	639	is akin, exempting the fact we're providing a way to make the eggs whole again
391	(the king's men would've loved such an option).</p>	640	(the king's men would've loved such an option).</p>
392	</div>	641	</div>
393	<div class="section" id="migrating-to-the-new-setup">	642	<div class="section">
394	<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>	643	<h2><a class="toc-backref" href="#id12" id="migrating-to-the-new-setup" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>
395	<p>As has been done in the past whenever a change in the tree results in ebuilds	644	<p>As has been done in the past whenever a change in the tree results in ebuilds
396	requiring a specific version of portage, as ebuilds migrate to the new eclasses,	645	requiring a specific version of portage, as ebuilds migrate to the new eclasses,
397	they should depend on a version of portage that supports it. From the users	646	they should depend on a version of portage that supports it. From the users
398	viewpoint, this transparently handles the migration.</p>	647	viewpoint, this transparently handles the migration.</p>
399	<p>This isn't so transparent for devs or a particular infrastructure server however.	648	<p>This isn't so transparent for devs or a particular infrastructure server however.
…		…
417	<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a	666	<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a
418	window in which to redesign it. It's humbly suggested eclass devs take	667	window in which to redesign it. It's humbly suggested eclass devs take
419	advantage of it. :)</p>	668	advantage of it. :)</p>
420	</div>	669	</div>
421	</div>	670	</div>
422	<div class="section" id="backwards-compatibility">	671	<div class="section">
423	<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1>	672	<h1><a class="toc-backref" href="#id13" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
424	<p>All backwards compatibility issues are addressed in line, but a recap is offered-	673	<p>All backwards compatibility issues are addressed in line, but a recap is offered-
425	it's suggested that if the a particular compatibility issue is	674	it's suggested that if the a particular compatibility issue is
426	questioned/worried over, the reader read the relevant section. There should be	675	questioned/worried over, the reader read the relevant section. There should be
427	a more in depth discussion of the issue, along with a more extensive explanation	676	a more in depth discussion of the issue, along with a more extensive explanation
428	of the potential solutions, and reasons for the chosen solution.</p>	677	of the potential solutions, and reasons for the chosen solution.</p>
…		…
436	'thinning' of available ebuilds should they block the portage upgrade is	685	'thinning' of available ebuilds should they block the portage upgrade is
437	their responsibility.	686	their responsibility.
438		687
439	Old eclasses at some point in the future should be removed from the tree,	688	Old eclasses at some point in the future should be removed from the tree,
440	and released in a tarball/ebuild. This will cause installed ebuilds that	689	and released in a tarball/ebuild. This will cause installed ebuilds that
441	rely on the old eclass to be unable to unmerge, with the same applying for	690	rely on the old eclass to be unable to unmerge, with the same applying for
442	merging of binpkgs dependent on the following paragraph.	691	merging of binpkgs dependent on the following paragraph.
443		692
444	The old eclass-compat is only required for users who do not upgrade their	693	The old eclass-compat is only required for users who do not upgrade their
445	portage installation, and one further exemption- if the user has somehow	694	portage installation, and one further exemption- if the user has somehow
446	corrupted/destroyed their installed pkgs database (/var/db/pkg currently),	695	corrupted/destroyed their installed pkgs database (/var/db/pkg currently),
447	in the process, they've lost their saved environments. The eclass-compat	696	in the process, they've lost their saved environments. The eclass-compat
448	ebuild would be required for ebuilds that required older eclasses in such a	697	ebuild would be required for ebuilds that required older eclasses in such a
449	case. Note, this case is rare also- as clarified above, it's mentioned	698	case. Note, this case is rare also- as clarified above, it's mentioned
450	strictly to be complete, it's not much of a real world scenario as elaborated	699	strictly to be complete, it's not much of a real world scenario as elaborated
451	above.	700	above.
452	</pre>	701	</pre>
453	</div>	702	</div>
454	<div class="section" id="copyright">	703	<div class="section">
455	<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1>	704	<h1><a class="toc-backref" href="#id14" id="copyright" name="copyright">Copyright</a></h1>
456	<p>This document has been placed in the public domain.</p>	705	<p>This document has been placed in the public domain.</p>
457	</div>	706	</div>
458		707
459	</div>	708	</div>
460	<div class="footer">	709	<div class="footer">
461	<hr class="footer" />	710	<hr class="footer" />
462	<a class="reference" href="glep-0033.txt">View document source</a>.	711	<a class="reference" href="glep-0033.txt">View document source</a>.
463	Generated on: 2005-09-15 02:37 UTC.	712	Generated on: 2006-09-05 20:55 UTC.
464	Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.	713	Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
465		714
466	</div>	715	</div>
467	</body>	716	</body>
468	</html>	717	</html>

 Legend:



Removed from v.1.3
 


changed lines


 
Added in v.1.5
 Legend:



Removed from v.1.3
 


changed lines


 
Added in v.1.5
-Removed from v.1.3
+Added in v.1.5

	ViewVC Help
Powered by ViewVC 1.1.13