1 |
<?xml version="1.0" encoding="utf-8" ?> |
2 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
3 |
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
4 |
<!-- |
5 |
This HTML is auto-generated. DO NOT EDIT THIS FILE! If you are writing a new |
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! |
8 |
--> |
9 |
<head> |
10 |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
11 |
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" /> |
12 |
<title>GLEP 37 -- Virtuals Deprecation</title> |
13 |
<style type="text/css"> |
14 |
|
15 |
/* |
16 |
:Author: David Goodger |
17 |
:Contact: goodger@users.sourceforge.net |
18 |
:date: $Date: 2003/06/02 17:03:08 $ |
19 |
:version: $Revision: 1.1 $ |
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> |
257 |
</head> |
258 |
<body bgcolor="white"> |
259 |
<table class="navigation" cellpadding="0" cellspacing="0" |
260 |
width="100%" border="0"> |
261 |
<tr><td class="navicon" width="150" height="35"> |
262 |
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> |
263 |
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" |
264 |
border="0" width="150" height="35" /></a></td> |
265 |
<td class="textlinks" align="left"> |
266 |
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] |
267 |
[<b><a href="http://www.gentoo.org/peps">GLEP Index</a></b>] |
268 |
[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0037.txt">GLEP Source</a></b>] |
269 |
</td></tr></table> |
270 |
<table class="rfc2822 docutils field-list" frame="void" rules="none"> |
271 |
<col class="field-name" /> |
272 |
<col class="field-body" /> |
273 |
<tbody valign="top"> |
274 |
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">37</td> |
275 |
</tr> |
276 |
<tr class="field"><th class="field-name">Title:</th><td class="field-body">Virtuals Deprecation</td> |
277 |
</tr> |
278 |
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td> |
279 |
</tr> |
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-0037.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td> |
281 |
</tr> |
282 |
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Jason Stubbs <jstubbs at gentoo.org></td> |
283 |
</tr> |
284 |
<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td> |
285 |
</tr> |
286 |
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
287 |
</tr> |
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> |
289 |
</tr> |
290 |
<tr class="field"><th class="field-name">Created:</th><td class="field-body">30-April-2005</td> |
291 |
</tr> |
292 |
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">30-April-2005, 5-Sep-2006</td> |
293 |
</tr> |
294 |
</tbody> |
295 |
</table> |
296 |
<hr /> |
297 |
<div class="contents topic"> |
298 |
<p class="topic-title first"><a id="contents" name="contents">Contents</a></p> |
299 |
<ul class="simple"> |
300 |
<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li> |
301 |
<li><a class="reference" href="#credits" id="id3" name="id3">Credits</a></li> |
302 |
<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li> |
303 |
<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li> |
304 |
<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul> |
305 |
<li><a class="reference" href="#consistency" id="id7" name="id7">Consistency</a></li> |
306 |
<li><a class="reference" href="#overrides" id="id8" name="id8">Overrides</a></li> |
307 |
</ul> |
308 |
</li> |
309 |
<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li> |
310 |
<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li> |
311 |
<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li> |
312 |
</ul> |
313 |
</div> |
314 |
<div class="section"> |
315 |
<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1> |
316 |
<p>What has been implemented so far diverges somewhat from what is |
317 |
stated in this GLEP. As such, this GLEP (in its current form) |
318 |
has been marked "deferred".</p> |
319 |
</div> |
320 |
<div class="section"> |
321 |
<h1><a class="toc-backref" href="#id3" id="credits" name="credits">Credits</a></h1> |
322 |
<p>Most ideas in this GLEP came out of discussion with Thomas de Grenier de |
323 |
Latour. Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided |
324 |
help in fleshing out the idea.</p> |
325 |
</div> |
326 |
<div class="section"> |
327 |
<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1> |
328 |
<p>This GLEP covers the pitfalls of the current virtuals system, the benefits of |
329 |
using regular ebuilds to serve the purpose of virtuals and what needs to be |
330 |
supported to make it viable.</p> |
331 |
</div> |
332 |
<div class="section"> |
333 |
<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1> |
334 |
<p>The current virtuals system is decentralized; that is there is no way to find |
335 |
information about a specific virtual other than to scan all packages for what |
336 |
they provide. There is also no way to tell whether an atom is a virtual or |
337 |
not - yes, the "virtual/" prefix could have been used but it isn't which has |
338 |
led to its abuse.</p> |
339 |
<p>What this means is that portage must scan all installed packages for the |
340 |
virtuals they provide, that profiles must provide a default for every single |
341 |
virtual that portage might encounter and that every single atom that portage |
342 |
processes must be checked against the list of virtuals. Needless to say that |
343 |
this causes quite a performance decrease.</p> |
344 |
<p>The current virtuals system also has some other major shortcomings. The most |
345 |
well known case is virtual/jdk and kaffe. Kaffe-1.1.4 implements the Java 1.4 |
346 |
API but can not satisfy a package that requires >=virtual/jdk-1.4 because |
347 |
kaffe's versioning scheme differs. (ED: Need to add some more here. ;)</p> |
348 |
</div> |
349 |
<div class="section"> |
350 |
<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1> |
351 |
<p>This GLEP recommends that virtuals become no different to regular packages. |
352 |
Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS, |
353 |
IUSE and RDEPEND metadata. An example would be something like this:</p> |
354 |
<pre class="literal-block"> |
355 |
DESCRIPTION="Java Development Kit 1.4" |
356 |
KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86" |
357 |
RDEPEND="|| ( |
358 |
=dev-java/blackdown-jdk-1.4\* |
359 |
=dev-java/ibm-jdk-bin-1.4* |
360 |
=dev-java/jrockit-jdk-bin-1.4* |
361 |
=dev-java/kaffe-1.1.4* |
362 |
=dev-java/sun-jdk-1.4* |
363 |
)" |
364 |
IUSE="" |
365 |
</pre> |
366 |
<p>However, there are some issues that have been brought up with doing this.</p> |
367 |
<div class="section"> |
368 |
<h2><a class="toc-backref" href="#id7" id="consistency" name="consistency">Consistency</a></h2> |
369 |
<p>Presently, it is very easy to remove packages even if others are dependent |
370 |
on them, which can lead to broken emerges when packages rely on indirect |
371 |
dependencies. For example, if kdelibs is merged bringing in qt and then |
372 |
qt is unmerged, attempting to merge kdebase will likely fail. This becomes |
373 |
a much bigger problem with virtuals as packages because the dependencies |
374 |
are always indirect.</p> |
375 |
<p>The resolution for this issue will be to add full dependency tracking and |
376 |
verification to portage. The details of how it will be done are outside the |
377 |
scope of this GLEP, but essentially this means that portage will need to be |
378 |
forced to unmerge a package that is depended on by another and will also be |
379 |
able to scan and fix any broken dependencies.</p> |
380 |
</div> |
381 |
<div class="section"> |
382 |
<h2><a class="toc-backref" href="#id8" id="overrides" name="overrides">Overrides</a></h2> |
383 |
<p>Profiles currently specify the default provider of each virtual and users are |
384 |
able to override these defaults using /etc/portage/profile/virtuals. If |
385 |
virtuals are replaced by regular packages and thus able to have arbitrarily |
386 |
complex DEPENDs, the current method of overriding default virtuals can not |
387 |
be extended to support this.</p> |
388 |
<p>Before looking at a solution, lets look at how the current system works. When |
389 |
portage initializes, it searches installed packages for available virtuals. |
390 |
It then searches profiles and user overrides and adds them to the available |
391 |
providers list and/or changes the order of the providers so that overrides are |
392 |
listed earlier. Portage then expands any virtual atom it finds into an OR |
393 |
list using the order decided upon at initialization.</p> |
394 |
<p>To keep this behaviour available, this GLEP proposes a new file named |
395 |
package.prefer. In its basic form, this is just a list of package names |
396 |
ordered by preference. Portage would use it by reordering the atoms of any |
397 |
OR list it processes to fit the order given by package.prefer. For example, |
398 |
if package.prefer contained "dev-java/kaffe" then:</p> |
399 |
<pre class="literal-block"> |
400 |
|| ( |
401 |
dev-java/blackdown-jdk |
402 |
dev-java/sun-jdk |
403 |
dev-java/kaffe |
404 |
) |
405 |
</pre> |
406 |
<p>would be processed as:</p> |
407 |
<pre class="literal-block"> |
408 |
|| ( |
409 |
dev-java/kaffe |
410 |
dev-java/blackdown-jdk |
411 |
dev-java/sun-jdk |
412 |
) |
413 |
</pre> |
414 |
<p>In its basic form, package.prefer already covers profile and user overrides. |
415 |
However, this GLEP proposes that any type of atom be usable. This will be |
416 |
accomplished by checking for intersections of the atoms in the OR list and |
417 |
atoms in the preferred list. When an intersection is found, both atoms |
418 |
would be specified in a sublist, which would then be treated as a ranged dep. |
419 |
For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:</p> |
420 |
<pre class="literal-block"> |
421 |
|| ( |
422 |
>=dev-java/blackdown-jdk-1.3 |
423 |
>=dev-java/sun-jdk-1.3 |
424 |
) |
425 |
</pre> |
426 |
<p>would be processed as:</p> |
427 |
<pre class="literal-block"> |
428 |
|| ( |
429 |
( |
430 |
<=dev-java/sun-jdk-1.4 |
431 |
>=dev-java/sun-jdk-1.3 |
432 |
) |
433 |
>=dev-java/blackdown-jdk-1.3 |
434 |
>=dev-java/sun-jdk-1.3 |
435 |
) |
436 |
</pre> |
437 |
<p>Ranged deps are outside of the scope of this GLEP.</p> |
438 |
</div> |
439 |
</div> |
440 |
<div class="section"> |
441 |
<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1> |
442 |
<p>The number one advantage is that it offers more power to both the user and |
443 |
the developer. Flexibility of virtuals is far greater in this scheme and |
444 |
fulfills requirements that exist already. It also means that the maintainers |
445 |
of profiles will not need to list a default for every virtual. The user |
446 |
benefits by being able to easily gather a list of providers of a virtual as |
447 |
well as their control being extended to allow selection where there is a |
448 |
choice within any package.</p> |
449 |
<p>Portage code also benefits from this scheme as virtuals will no longer |
450 |
require special handling or dual implementations of essentially the same |
451 |
feature, for example USE-based PROVIDEs. This scheme is also much easier to |
452 |
optimize which will benefit the processing of all packages. It also means |
453 |
that any additions to the DEPEND vocabulary become available for use in the |
454 |
definitions of virtuals.</p> |
455 |
</div> |
456 |
<div class="section"> |
457 |
<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1> |
458 |
<p>Compatibility will begin by making 2.0.51.20 treat unknown virtuals like |
459 |
regular packages. When the tree is stripped of PROVIDEs and "virtuals" |
460 |
override files, the only virtuals that these portages will use are those that |
461 |
the user has specified and those gleaned from installed packages. Any |
462 |
unknown virtual will be treated like a regular package and looked for in the |
463 |
tree.</p> |
464 |
<p>The next major version of portage (2.1.0) will support consistency |
465 |
checking. The only remaining issue is that of user overrides. The old |
466 |
method will work even with new style virtuals. The only catch is that |
467 |
complex virtuals - that is virtuals that will install more than one package - |
468 |
may not be overridable satisfactorally.</p> |
469 |
<p>Dropping of support of current style virtuals is planned for the following |
470 |
major version of portage (2.2.0). When the time comes to release it, scripts |
471 |
will be written to create packages from the existing virtuals system as well |
472 |
as to create appropriate package.prefer overrides within the profiles.</p> |
473 |
</div> |
474 |
<div class="section"> |
475 |
<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1> |
476 |
<p>This document has been placed in the public domain.</p> |
477 |
</div> |
478 |
|
479 |
</div> |
480 |
<div class="footer"> |
481 |
<hr class="footer" /> |
482 |
<a class="reference" href="glep-0037.txt">View document source</a>. |
483 |
Generated on: 2006-10-10 20:23 UTC. |
484 |
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. |
485 |
|
486 |
</div> |
487 |
</body> |
488 |
</html> |
489 |
|