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 @@

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