en/glep/glep-0037.html

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<!--
This HTML is auto-generated.  DO NOT EDIT THIS FILE!  If you are writing a new
PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
to templates.  DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
-->
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
  <title>GLEP 37 -- Virtuals Deprecation</title>
  <style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2003/06/02 17:03:08 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the PEP HTML output of Docutils.
*/

.first {
  margin-top: 0 }

.last {
  margin-bottom: 0 }

.navigation {
  width: 100% ;
  background: #cc99ff ;
  margin-top: 0px ;
  margin-bottom: 0px }

.navigation .navicon {
  width: 150px ;
  height: 35px }

.navigation .textlinks {
  padding-left: 1em ;
  text-align: left }

.navigation td, .navigation th {
  padding-left: 0em ;
  padding-right: 0em ;
  vertical-align: middle }

.rfc2822 {
  margin-top: 0.5em ;
  margin-left: 0.5em ;
  margin-right: 0.5em ;
  margin-bottom: 0em }

.rfc2822 td {
  text-align: left }

.rfc2822 th.field-name {
  text-align: right ;
  font-family: sans-serif ;
  padding-right: 0.5em ;
  font-weight: bold ;
  margin-bottom: 0em }

a.toc-backref {
  text-decoration: none ;
  color: black }

body {
  margin: 0px ;
  margin-bottom: 1em ;
  padding: 0px }

dd {
  margin-bottom: 0.5em }

div.section {
  margin-left: 1em ;
  margin-right: 1em ;
  margin-bottom: 1.5em }

div.section div.section {
  margin-left: 0em ;
  margin-right: 0em ;
  margin-top: 1.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.footer {
  margin-left: 1em ;
  margin-right: 1em }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: sans-serif ;
  font-size: large }

h2 {
  font-family: sans-serif ;
  font-size: medium }

h3 {
  font-family: sans-serif ;
  font-size: small }

h4 {
  font-family: sans-serif ;
  font-style: italic ;
  font-size: small }

h5 {
  font-family: sans-serif;
  font-size: x-small }

h6 {
  font-family: sans-serif;
  font-style: italic ;
  font-size: x-small }

.section hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.topic-title {
  font-family: sans-serif ;
  font-weight: bold }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

td.num {
  text-align: right }

th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {
  background-color: #eeeeee }

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body bgcolor="white">
<table class="navigation" cellpadding="0" cellspacing="0"
       width="100%" border="0">
<tr><td class="navicon" width="150" height="35">
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
 border="0" width="150" height="35" /></a></td>
<td class="textlinks" align="left">
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
[<b><a href="http://www.gentoo.org/peps">GLEP Index</a></b>]
[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0037.txt">GLEP Source</a></b>]
</td></tr></table>
<table class="rfc2822 docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">37</td>
</tr>
<tr class="field"><th class="field-name">Title:</th><td class="field-body">Virtuals Deprecation</td>
</tr>
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Jason Stubbs &lt;jstubbs&#32;&#97;t&#32;gentoo.org&gt;</td>
</tr>
<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
</tr>
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Created:</th><td class="field-body">30-April-2005</td>
</tr>
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">30-April-2005, 5-Sep-2006</td>
</tr>
</tbody>
</table>
<hr />
<div class="contents topic">
<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
<ul class="simple">
<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
<li><a class="reference" href="#credits" id="id3" name="id3">Credits</a></li>
<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
<li><a class="reference" href="#consistency" id="id7" name="id7">Consistency</a></li>
<li><a class="reference" href="#overrides" id="id8" name="id8">Overrides</a></li>
</ul>
</li>
<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li>
<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
</ul>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
<p>What has been implemented so far diverges somewhat from what is
stated in this GLEP.  As such, this GLEP (in its current form)
has been marked &quot;deferred&quot;.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id3" id="credits" name="credits">Credits</a></h1>
<p>Most ideas in this GLEP came out of discussion with Thomas de Grenier de
Latour.  Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
help in fleshing out the idea.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
<p>This GLEP covers the pitfalls of the current virtuals system, the benefits of
using regular ebuilds to serve the purpose of virtuals and what needs to be
supported to make it viable.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
<p>The current virtuals system is decentralized; that is there is no way to find
information about a specific virtual other than to scan all packages for what
they provide.  There is also no way to tell whether an atom is a virtual or
not - yes, the &quot;virtual/&quot; prefix could have been used but it isn't which has
led to its abuse.</p>
<p>What this means is that portage must scan all installed packages for the
virtuals they provide, that profiles must provide a default for every single
virtual that portage might encounter and that every single atom that portage
processes must be checked against the list of virtuals.  Needless to say that
this causes quite a performance decrease.</p>
<p>The current virtuals system also has some other major shortcomings.  The most
well known case is virtual/jdk and kaffe.  Kaffe-1.1.4 implements the Java 1.4
API but can not satisfy a package that requires &gt;=virtual/jdk-1.4 because
kaffe's versioning scheme differs.  (ED: Need to add some more here. ;)</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
<p>This GLEP recommends that virtuals become no different to regular packages.
Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
IUSE and RDEPEND metadata.  An example would be something like this:</p>
<pre class="literal-block">
DESCRIPTION=&quot;Java Development Kit 1.4&quot;
KEYWORDS=&quot;amd64 hppa ia64 ppc ppc64 sparc x86&quot;
RDEPEND=&quot;|| (
             =dev-java/blackdown-jdk-1.4\*
             =dev-java/ibm-jdk-bin-1.4*
             =dev-java/jrockit-jdk-bin-1.4*
             =dev-java/kaffe-1.1.4*
             =dev-java/sun-jdk-1.4*
            )&quot;
IUSE=&quot;&quot;
</pre>
<p>However, there are some issues that have been brought up with doing this.</p>
<div class="section">
<h2><a class="toc-backref" href="#id7" id="consistency" name="consistency">Consistency</a></h2>
<p>Presently, it is very easy to remove packages even if others are dependent
on them, which can lead to broken emerges when packages rely on indirect
dependencies.  For example, if kdelibs is merged bringing in qt and then
qt is unmerged, attempting to merge kdebase will likely fail.  This becomes
a much bigger problem with virtuals as packages because the dependencies
are always indirect.</p>
<p>The resolution for this issue will be to add full dependency tracking and
verification to portage.  The details of how it will be done are outside the
scope of this GLEP, but essentially this means that portage will need to be
forced to unmerge a package that is depended on by another and will also be
able to scan and fix any broken dependencies.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id8" id="overrides" name="overrides">Overrides</a></h2>
<p>Profiles currently specify the default provider of each virtual and users are
able to override these defaults using /etc/portage/profile/virtuals.  If
virtuals are replaced by regular packages and thus able to have arbitrarily
complex DEPENDs, the current method of overriding default virtuals can not
be extended to support this.</p>
<p>Before looking at a solution, lets look at how the current system works.  When
portage initializes, it searches installed packages for available virtuals.
It then searches profiles and user overrides and adds them to the available
providers list and/or changes the order of the providers so that overrides are
listed earlier.  Portage then expands any virtual atom it finds into an OR
list using the order decided upon at initialization.</p>
<p>To keep this behaviour available, this GLEP proposes a new file named
package.prefer.  In its basic form, this is just a list of package names
ordered by preference.  Portage would use it by reordering the atoms of any
OR list it processes to fit the order given by package.prefer.  For example,
if package.prefer contained &quot;dev-java/kaffe&quot; then:</p>
<pre class="literal-block">
|| (
    dev-java/blackdown-jdk
    dev-java/sun-jdk
    dev-java/kaffe
   )
</pre>
<p>would be processed as:</p>
<pre class="literal-block">
|| (
    dev-java/kaffe
    dev-java/blackdown-jdk
    dev-java/sun-jdk
   )
</pre>
<p>In its basic form, package.prefer already covers profile and user overrides.
However, this GLEP proposes that any type of atom be usable.  This will be
accomplished by checking for intersections of the atoms in the OR list and
atoms in the preferred list.  When an intersection is found, both atoms
would be specified in a sublist, which would then be treated as a ranged dep.
For example, if package.prefer contained &quot;&lt;=dev-java/sun-jdk-1.4&quot; then:</p>
<pre class="literal-block">
|| (
    &gt;=dev-java/blackdown-jdk-1.3
    &gt;=dev-java/sun-jdk-1.3
   )
</pre>
<p>would be processed as:</p>
<pre class="literal-block">
|| (
    (
      &lt;=dev-java/sun-jdk-1.4
      &gt;=dev-java/sun-jdk-1.3
    )
    &gt;=dev-java/blackdown-jdk-1.3
    &gt;=dev-java/sun-jdk-1.3
   )
</pre>
<p>Ranged deps are outside of the scope of this GLEP.</p>
</div>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
<p>The number one advantage is that it offers more power to both the user and
the developer.  Flexibility of virtuals is far greater in this scheme and
fulfills requirements that exist already.  It also means that the maintainers
of profiles will not need to list a default for every virtual.  The user
benefits by being able to easily gather a list of providers of a virtual as
well as their control being extended to allow selection where there is a
choice within any package.</p>
<p>Portage code also benefits from this scheme as virtuals will no longer
require special handling or dual implementations of essentially the same
feature, for example USE-based PROVIDEs.  This scheme is also much easier to
optimize which will benefit the processing of all packages.  It also means
that any additions to the DEPEND vocabulary become available for use in the
definitions of virtuals.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
<p>Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
regular packages.  When the tree is stripped of PROVIDEs and &quot;virtuals&quot;
override files, the only virtuals that these portages will use are those that
the user has specified and those gleaned from installed packages.  Any
unknown virtual will be treated like a regular package and looked for in the
tree.</p>
<p>The next major version of portage (2.1.0) will support consistency
checking.  The only remaining issue is that of user overrides.  The old
method will work even with new style virtuals.  The only catch is that
complex virtuals - that is virtuals that will install more than one package -
may not be overridable satisfactorally.</p>
<p>Dropping of support of current style virtuals is planned for the following
major version of portage (2.2.0).  When the time comes to release it, scripts
will be written to create packages from the existing virtuals system as well
as to create appropriate package.prefer overrides within the profiles.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
<p>This document has been placed in the public domain.</p>
</div>

</div>
<div class="footer">
<hr class="footer" />
<a class="reference" href="glep-0037.txt">View document source</a>.
Generated on: 2006-10-10 20:23 UTC.
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.

</div>
</body>
</html>

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