--- xml/htdocs/proj/en/glep/glep-0037.html 2005/04/30 22:37:31 1.1 +++ xml/htdocs/proj/en/glep/glep-0037.html 2006/09/05 20:55:13 1.2 @@ -8,9 +8,252 @@ --> - + GLEP 37 -- Virtuals Deprecation - + @@ -32,55 +275,62 @@ - + - + - + - + - +
Title:Virtuals Deprecation
Version:1.1
Version:1.2
Last-Modified:2005/04/30 22:35:58
Last-Modified:2006/09/05 20:54:30
Author:Jason Stubbs <jstubbs at gentoo.org>
Status:Draft
Status:deferred
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:30-April-2005
Post-History:30-April-2005
Post-History:30-April-2005, 5-Sep-2006

-
-

Contents

+
+

Contents

-
-

Credits

+
+

Status

+

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

+
+
+

Credits

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.

-
-

Abstract

+
+

Abstract

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.

-
-

Motivation

+
+

Motivation

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 @@ -96,8 +346,8 @@ API but can not satisfy a package that requires >=virtual/jdk-1.4 because kaffe's versioning scheme differs. (ED: Need to add some more here. ;)

-
-

Specification

+
+

Specification

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:

@@ -114,8 +364,8 @@ IUSE=""

However, there are some issues that have been brought up with doing this.

-
-

Consistency

+
+

Consistency

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 @@ -128,8 +378,8 @@ forced to unmerge a package that is depended on by another and will also be able to scan and fix any broken dependencies.

-
-

Overrides

+
+

Overrides

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 @@ -187,8 +437,8 @@

Ranged deps are outside of the scope of this GLEP.

-
-

Rationale

+
+

Rationale

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 @@ -203,8 +453,8 @@ that any additions to the DEPEND vocabulary become available for use in the definitions of virtuals.

-
-

Backwards Compatibility

+
+

Backwards Compatibility

Compatibility will begin by making 2.0.51.20 treat unknown virtuals like regular packages. When the tree is stripped of PROVIDEs and "virtuals" override files, the only virtuals that these portages will use are those that @@ -221,17 +471,18 @@ will be written to create packages from the existing virtuals system as well as to create appropriate package.prefer overrides within the profiles.

- -