--- 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 @@ -->- +
|Author:||Jason Stubbs <jstubbs at gentoo.org>|
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".+
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.
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.
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. ;)
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.-
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.
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.
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.
Compatibility will begin by making 18.104.22.168 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.