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">

<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>
  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
</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/proj/en/glep">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: 2007-10-13 13:39 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	g2boojum	1.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	antarus	1.5
5	g2boojum	1.1	<head>
6			<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
7	g2boojum	1.2	<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
8	g2boojum	1.1	<title>GLEP 37 -- Virtuals Deprecation</title>
9	antarus	1.5	<link rel="stylesheet" href="tools/glep.css" type="text/css" />
10	g2boojum	1.1	</head>
11			<body bgcolor="white">
12			<table class="navigation" cellpadding="0" cellspacing="0"
13			width="100%" border="0">
14			<tr><td class="navicon" width="150" height="35">
15			<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
16			<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
17			border="0" width="150" height="35" /></a></td>
18			<td class="textlinks" align="left">
19			[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
20	antarus	1.5	[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
21	g2boojum	1.2	[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0037.txt">GLEP Source</a></b>]
22	g2boojum	1.1	</td></tr></table>
23			<table class="rfc2822 docutils field-list" frame="void" rules="none">
24			<col class="field-name" />
25			<col class="field-body" />
26			<tbody valign="top">
27			<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">37</td>
28			</tr>
29			<tr class="field"><th class="field-name">Title:</th><td class="field-body">Virtuals Deprecation</td>
30			</tr>
31	g2boojum	1.2	<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td>
32	g2boojum	1.1	</tr>
33	g2boojum	1.2	<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>
34	g2boojum	1.1	</tr>
35			<tr class="field"><th class="field-name">Author:</th><td class="field-body">Jason Stubbs <jstubbs at gentoo.org></td>
36			</tr>
37	g2boojum	1.2	<tr class="field"><th class="field-name">Status:</th><td class="field-body">deferred</td>
38	g2boojum	1.1	</tr>
39			<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
40			</tr>
41	g2boojum	1.2	<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>
42	g2boojum	1.1	</tr>
43			<tr class="field"><th class="field-name">Created:</th><td class="field-body">30-April-2005</td>
44			</tr>
45	g2boojum	1.2	<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">30-April-2005, 5-Sep-2006</td>
46	g2boojum	1.1	</tr>
47			</tbody>
48			</table>
49			<hr />
50	g2boojum	1.2	<div class="contents topic">
51			<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
52	g2boojum	1.1	<ul class="simple">
53	g2boojum	1.2	<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
54			<li><a class="reference" href="#credits" id="id3" name="id3">Credits</a></li>
55			<li><a class="reference" href="#abstract" id="id4" name="id4">Abstract</a></li>
56			<li><a class="reference" href="#motivation" id="id5" name="id5">Motivation</a></li>
57			<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
58			<li><a class="reference" href="#consistency" id="id7" name="id7">Consistency</a></li>
59			<li><a class="reference" href="#overrides" id="id8" name="id8">Overrides</a></li>
60	g2boojum	1.1	</ul>
61			</li>
62	g2boojum	1.2	<li><a class="reference" href="#rationale" id="id9" name="id9">Rationale</a></li>
63			<li><a class="reference" href="#backwards-compatibility" id="id10" name="id10">Backwards Compatibility</a></li>
64			<li><a class="reference" href="#copyright" id="id11" name="id11">Copyright</a></li>
65	g2boojum	1.1	</ul>
66			</div>
67	g2boojum	1.2	<div class="section">
68			<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
69			<p>What has been implemented so far diverges somewhat from what is
70			stated in this GLEP. As such, this GLEP (in its current form)
71			has been marked "deferred".</p>
72			</div>
73			<div class="section">
74			<h1><a class="toc-backref" href="#id3" id="credits" name="credits">Credits</a></h1>
75	g2boojum	1.1	<p>Most ideas in this GLEP came out of discussion with Thomas de Grenier de
76			Latour. Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
77			help in fleshing out the idea.</p>
78			</div>
79	g2boojum	1.2	<div class="section">
80			<h1><a class="toc-backref" href="#id4" id="abstract" name="abstract">Abstract</a></h1>
81	g2boojum	1.1	<p>This GLEP covers the pitfalls of the current virtuals system, the benefits of
82			using regular ebuilds to serve the purpose of virtuals and what needs to be
83			supported to make it viable.</p>
84			</div>
85	g2boojum	1.2	<div class="section">
86			<h1><a class="toc-backref" href="#id5" id="motivation" name="motivation">Motivation</a></h1>
87	g2boojum	1.1	<p>The current virtuals system is decentralized; that is there is no way to find
88			information about a specific virtual other than to scan all packages for what
89			they provide. There is also no way to tell whether an atom is a virtual or
90			not - yes, the "virtual/" prefix could have been used but it isn't which has
91			led to its abuse.</p>
92			<p>What this means is that portage must scan all installed packages for the
93			virtuals they provide, that profiles must provide a default for every single
94			virtual that portage might encounter and that every single atom that portage
95			processes must be checked against the list of virtuals. Needless to say that
96			this causes quite a performance decrease.</p>
97			<p>The current virtuals system also has some other major shortcomings. The most
98			well known case is virtual/jdk and kaffe. Kaffe-1.1.4 implements the Java 1.4
99			API but can not satisfy a package that requires >=virtual/jdk-1.4 because
100			kaffe's versioning scheme differs. (ED: Need to add some more here. ;)</p>
101			</div>
102	g2boojum	1.2	<div class="section">
103			<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
104	g2boojum	1.1	<p>This GLEP recommends that virtuals become no different to regular packages.
105			Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
106			IUSE and RDEPEND metadata. An example would be something like this:</p>
107			<pre class="literal-block">
108			DESCRIPTION="Java Development Kit 1.4"
109			KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
110			RDEPEND="\|\| (
111			=dev-java/blackdown-jdk-1.4\*
112			=dev-java/ibm-jdk-bin-1.4*
113			=dev-java/jrockit-jdk-bin-1.4*
114			=dev-java/kaffe-1.1.4*
115			=dev-java/sun-jdk-1.4*
116			)"
117			IUSE=""
118			</pre>
119			<p>However, there are some issues that have been brought up with doing this.</p>
120	g2boojum	1.2	<div class="section">
121			<h2><a class="toc-backref" href="#id7" id="consistency" name="consistency">Consistency</a></h2>
122	g2boojum	1.1	<p>Presently, it is very easy to remove packages even if others are dependent
123			on them, which can lead to broken emerges when packages rely on indirect
124			dependencies. For example, if kdelibs is merged bringing in qt and then
125			qt is unmerged, attempting to merge kdebase will likely fail. This becomes
126			a much bigger problem with virtuals as packages because the dependencies
127			are always indirect.</p>
128			<p>The resolution for this issue will be to add full dependency tracking and
129			verification to portage. The details of how it will be done are outside the
130			scope of this GLEP, but essentially this means that portage will need to be
131			forced to unmerge a package that is depended on by another and will also be
132			able to scan and fix any broken dependencies.</p>
133			</div>
134	g2boojum	1.2	<div class="section">
135			<h2><a class="toc-backref" href="#id8" id="overrides" name="overrides">Overrides</a></h2>
136	g2boojum	1.1	<p>Profiles currently specify the default provider of each virtual and users are
137			able to override these defaults using /etc/portage/profile/virtuals. If
138			virtuals are replaced by regular packages and thus able to have arbitrarily
139			complex DEPENDs, the current method of overriding default virtuals can not
140			be extended to support this.</p>
141			<p>Before looking at a solution, lets look at how the current system works. When
142			portage initializes, it searches installed packages for available virtuals.
143			It then searches profiles and user overrides and adds them to the available
144			providers list and/or changes the order of the providers so that overrides are
145			listed earlier. Portage then expands any virtual atom it finds into an OR
146			list using the order decided upon at initialization.</p>
147			<p>To keep this behaviour available, this GLEP proposes a new file named
148			package.prefer. In its basic form, this is just a list of package names
149			ordered by preference. Portage would use it by reordering the atoms of any
150			OR list it processes to fit the order given by package.prefer. For example,
151			if package.prefer contained "dev-java/kaffe" then:</p>
152			<pre class="literal-block">
153			\|\| (
154			dev-java/blackdown-jdk
155			dev-java/sun-jdk
156			dev-java/kaffe
157			)
158			</pre>
159			<p>would be processed as:</p>
160			<pre class="literal-block">
161			\|\| (
162			dev-java/kaffe
163			dev-java/blackdown-jdk
164			dev-java/sun-jdk
165			)
166			</pre>
167			<p>In its basic form, package.prefer already covers profile and user overrides.
168			However, this GLEP proposes that any type of atom be usable. This will be
169			accomplished by checking for intersections of the atoms in the OR list and
170			atoms in the preferred list. When an intersection is found, both atoms
171			would be specified in a sublist, which would then be treated as a ranged dep.
172			For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:</p>
173			<pre class="literal-block">
174			\|\| (
175			>=dev-java/blackdown-jdk-1.3
176			>=dev-java/sun-jdk-1.3
177			)
178			</pre>
179			<p>would be processed as:</p>
180			<pre class="literal-block">
181			\|\| (
182			(
183			<=dev-java/sun-jdk-1.4
184			>=dev-java/sun-jdk-1.3
185			)
186			>=dev-java/blackdown-jdk-1.3
187			>=dev-java/sun-jdk-1.3
188			)
189			</pre>
190			<p>Ranged deps are outside of the scope of this GLEP.</p>
191			</div>
192			</div>
193	g2boojum	1.2	<div class="section">
194			<h1><a class="toc-backref" href="#id9" id="rationale" name="rationale">Rationale</a></h1>
195	g2boojum	1.1	<p>The number one advantage is that it offers more power to both the user and
196			the developer. Flexibility of virtuals is far greater in this scheme and
197			fulfills requirements that exist already. It also means that the maintainers
198			of profiles will not need to list a default for every virtual. The user
199			benefits by being able to easily gather a list of providers of a virtual as
200			well as their control being extended to allow selection where there is a
201			choice within any package.</p>
202			<p>Portage code also benefits from this scheme as virtuals will no longer
203			require special handling or dual implementations of essentially the same
204			feature, for example USE-based PROVIDEs. This scheme is also much easier to
205			optimize which will benefit the processing of all packages. It also means
206			that any additions to the DEPEND vocabulary become available for use in the
207			definitions of virtuals.</p>
208			</div>
209	g2boojum	1.2	<div class="section">
210			<h1><a class="toc-backref" href="#id10" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
211	g2boojum	1.1	<p>Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
212			regular packages. When the tree is stripped of PROVIDEs and "virtuals"
213			override files, the only virtuals that these portages will use are those that
214			the user has specified and those gleaned from installed packages. Any
215			unknown virtual will be treated like a regular package and looked for in the
216			tree.</p>
217			<p>The next major version of portage (2.1.0) will support consistency
218			checking. The only remaining issue is that of user overrides. The old
219			method will work even with new style virtuals. The only catch is that
220			complex virtuals - that is virtuals that will install more than one package -
221			may not be overridable satisfactorally.</p>
222			<p>Dropping of support of current style virtuals is planned for the following
223			major version of portage (2.2.0). When the time comes to release it, scripts
224			will be written to create packages from the existing virtuals system as well
225			as to create appropriate package.prefer overrides within the profiles.</p>
226			</div>
227	g2boojum	1.2	<div class="section">
228			<h1><a class="toc-backref" href="#id11" id="copyright" name="copyright">Copyright</a></h1>
229	g2boojum	1.1	<p>This document has been placed in the public domain.</p>
230			</div>
231
232			</div>
233			<div class="footer">
234	g2boojum	1.2	<hr class="footer" />
235	g2boojum	1.1	<a class="reference" href="glep-0037.txt">View document source</a>.
236	antarus	1.5	Generated on: 2007-10-13 13:39 UTC.
237	g2boojum	1.1	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.
238	g2boojum	1.2
239	g2boojum	1.1	</div>
240			</body>
241			</html>