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

Contents of /xml/htdocs/proj/en/glep/glep-0037.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download) (as text)
Sat Apr 30 22:37:31 2005 UTC (8 years, 11 months ago) by g2boojum
Branch: MAIN
File MIME type: text/html
new glep

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

  ViewVC Help
Powered by ViewVC 1.1.20