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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download)
Sat Apr 30 22:35:58 2005 UTC (9 years, 2 months ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
new glep

1 g2boojum 1.1 GLEP: 37
2     Title: Virtuals Deprecation
3     Version: $Revision: 1.4 $
4     Last-Modified: $Date: 2003/07/19 12:09:20 $
5     Author: Jason Stubbs <jstubbs@gentoo.org>
6     Status: Draft
7     Type: Standards Track
8     Content-Type: text/x-rst
9     Created: 30-April-2005
10     Post-History: 30-April-2005
11    
12    
13     Credits
14     =======
15    
16     Most ideas in this GLEP came out of discussion with Thomas de Grenier de
17     Latour. Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
18     help in fleshing out the idea.
19    
20    
21     Abstract
22     ========
23    
24     This GLEP covers the pitfalls of the current virtuals system, the benefits of
25     using regular ebuilds to serve the purpose of virtuals and what needs to be
26     supported to make it viable.
27    
28    
29     Motivation
30     ==========
31    
32     The current virtuals system is decentralized; that is there is no way to find
33     information about a specific virtual other than to scan all packages for what
34     they provide. There is also no way to tell whether an atom is a virtual or
35     not - yes, the "virtual/" prefix could have been used but it isn't which has
36     led to its abuse.
37    
38     What this means is that portage must scan all installed packages for the
39     virtuals they provide, that profiles must provide a default for every single
40     virtual that portage might encounter and that every single atom that portage
41     processes must be checked against the list of virtuals. Needless to say that
42     this causes quite a performance decrease.
43    
44     The current virtuals system also has some other major shortcomings. The most
45     well known case is virtual/jdk and kaffe. Kaffe-1.1.4 implements the Java 1.4
46     API but can not satisfy a package that requires >=virtual/jdk-1.4 because
47     kaffe's versioning scheme differs. (ED: Need to add some more here. ;)
48    
49    
50     Specification
51     =============
52    
53     This GLEP recommends that virtuals become no different to regular packages.
54     Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
55     IUSE and RDEPEND metadata. An example would be something like this::
56    
57     DESCRIPTION="Java Development Kit 1.4"
58     KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
59     RDEPEND="|| (
60     =dev-java/blackdown-jdk-1.4\*
61     =dev-java/ibm-jdk-bin-1.4*
62     =dev-java/jrockit-jdk-bin-1.4*
63     =dev-java/kaffe-1.1.4*
64     =dev-java/sun-jdk-1.4*
65     )"
66     IUSE=""
67    
68     However, there are some issues that have been brought up with doing this.
69    
70    
71     Consistency
72     -----------
73    
74     Presently, it is very easy to remove packages even if others are dependent
75     on them, which can lead to broken emerges when packages rely on indirect
76     dependencies. For example, if kdelibs is merged bringing in qt and then
77     qt is unmerged, attempting to merge kdebase will likely fail. This becomes
78     a much bigger problem with virtuals as packages because the dependencies
79     are always indirect.
80    
81     The resolution for this issue will be to add full dependency tracking and
82     verification to portage. The details of how it will be done are outside the
83     scope of this GLEP, but essentially this means that portage will need to be
84     forced to unmerge a package that is depended on by another and will also be
85     able to scan and fix any broken dependencies.
86    
87    
88     Overrides
89     ---------
90    
91     Profiles currently specify the default provider of each virtual and users are
92     able to override these defaults using /etc/portage/profile/virtuals. If
93     virtuals are replaced by regular packages and thus able to have arbitrarily
94     complex DEPENDs, the current method of overriding default virtuals can not
95     be extended to support this.
96    
97     Before looking at a solution, lets look at how the current system works. When
98     portage initializes, it searches installed packages for available virtuals.
99     It then searches profiles and user overrides and adds them to the available
100     providers list and/or changes the order of the providers so that overrides are
101     listed earlier. Portage then expands any virtual atom it finds into an OR
102     list using the order decided upon at initialization.
103    
104     To keep this behaviour available, this GLEP proposes a new file named
105     package.prefer. In its basic form, this is just a list of package names
106     ordered by preference. Portage would use it by reordering the atoms of any
107     OR list it processes to fit the order given by package.prefer. For example,
108     if package.prefer contained "dev-java/kaffe" then:
109    
110     ::
111    
112     || (
113     dev-java/blackdown-jdk
114     dev-java/sun-jdk
115     dev-java/kaffe
116     )
117    
118     would be processed as:
119    
120     ::
121    
122     || (
123     dev-java/kaffe
124     dev-java/blackdown-jdk
125     dev-java/sun-jdk
126     )
127    
128     In its basic form, package.prefer already covers profile and user overrides.
129     However, this GLEP proposes that any type of atom be usable. This will be
130     accomplished by checking for intersections of the atoms in the OR list and
131     atoms in the preferred list. When an intersection is found, both atoms
132     would be specified in a sublist, which would then be treated as a ranged dep.
133     For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:
134    
135     ::
136    
137     || (
138     >=dev-java/blackdown-jdk-1.3
139     >=dev-java/sun-jdk-1.3
140     )
141    
142     would be processed as:
143    
144     ::
145    
146     || (
147     (
148     <=dev-java/sun-jdk-1.4
149     >=dev-java/sun-jdk-1.3
150     )
151     >=dev-java/blackdown-jdk-1.3
152     >=dev-java/sun-jdk-1.3
153     )
154    
155     Ranged deps are outside of the scope of this GLEP.
156    
157    
158     Rationale
159     =========
160    
161     The number one advantage is that it offers more power to both the user and
162     the developer. Flexibility of virtuals is far greater in this scheme and
163     fulfills requirements that exist already. It also means that the maintainers
164     of profiles will not need to list a default for every virtual. The user
165     benefits by being able to easily gather a list of providers of a virtual as
166     well as their control being extended to allow selection where there is a
167     choice within any package.
168    
169     Portage code also benefits from this scheme as virtuals will no longer
170     require special handling or dual implementations of essentially the same
171     feature, for example USE-based PROVIDEs. This scheme is also much easier to
172     optimize which will benefit the processing of all packages. It also means
173     that any additions to the DEPEND vocabulary become available for use in the
174     definitions of virtuals.
175    
176    
177     Backwards Compatibility
178     =======================
179    
180     Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
181     regular packages. When the tree is stripped of PROVIDEs and "virtuals"
182     override files, the only virtuals that these portages will use are those that
183     the user has specified and those gleaned from installed packages. Any
184     unknown virtual will be treated like a regular package and looked for in the
185     tree.
186    
187     The next major version of portage (2.1.0) will support consistency
188     checking. The only remaining issue is that of user overrides. The old
189     method will work even with new style virtuals. The only catch is that
190     complex virtuals - that is virtuals that will install more than one package -
191     may not be overridable satisfactorally.
192    
193     Dropping of support of current style virtuals is planned for the following
194     major version of portage (2.2.0). When the time comes to release it, scripts
195     will be written to create packages from the existing virtuals system as well
196     as to create appropriate package.prefer overrides within the profiles.
197    
198    
199     Copyright
200     =========
201    
202     This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20