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

Parent Directory Parent Directory | Revision Log Revision Log

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

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
13 Credits
14 =======
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.
21 Abstract
22 ========
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.
29 Motivation
30 ==========
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.
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.
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. ;)
50 Specification
51 =============
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::
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=""
68 However, there are some issues that have been brought up with doing this.
71 Consistency
72 -----------
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.
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.
88 Overrides
89 ---------
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.
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.
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:
110 ::
112 || (
113 dev-java/blackdown-jdk
114 dev-java/sun-jdk
115 dev-java/kaffe
116 )
118 would be processed as:
120 ::
122 || (
123 dev-java/kaffe
124 dev-java/blackdown-jdk
125 dev-java/sun-jdk
126 )
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:
135 ::
137 || (
138 >=dev-java/blackdown-jdk-1.3
139 >=dev-java/sun-jdk-1.3
140 )
142 would be processed as:
144 ::
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 )
155 Ranged deps are outside of the scope of this GLEP.
158 Rationale
159 =========
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.
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.
177 Backwards Compatibility
178 =======================
180 Compatibility will begin by making 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.
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.
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.
199 Copyright
200 =========
202 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20