+Virtuals
+
+
+
+Currently there exist two different forms of virtuals, our regular
+PROVIDE type virtuals, and so called new-style virtuals.
+
+
+
+
+<e>Old-style</e> Virtuals
+
+
+Old-style virtuals are not really packages, but are something you can depend
+upon and install. All old-style virtuals must have a category of
+"virtual". In order to use an old-style virtual there are a few things
+that need to be present in the tree:
+
+
+ -
+ Atleast one ebuild must PROVIDE the virtual see
+
+
+ -
+ An entry in the virtuals file for each profile to list the default provider
+
+
+
+Old-style virtuals are not as flexible as new-style virtuals
+because there is no concept of a version. You can only depend upon a virtual,
+but not a particular version of that virtual.
+
+
+
+
+
+<e>New-style</e> Virtuals
+
+
+New-style virtuals are merely packages that are in the category of
+virtual. They use their dependency string to specify the providers for
+the virtual and should not install any files. Since they are regular ebuilds,
+there can be several versions of a virtual (which can be helpful when a package
+may be provided by another in some versions, and not others see the perl
+virtuals for an example of this).
+
+
+
+An example of a new-style virtual:
+
+
+DESCRIPTION="Virtual for C++ tr1 <type_traits>"
+HOMEPAGE="http://www.gentoo.org/proj/en/base/"
+SRC_URI=""
+LICENSE="as-is"
+SLOT="0"
+KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sparc x86 ~x86-fbsd"
+IUSE=""
+RDEPEND="|| ( >=sys-devel/gcc-4.1 dev-libs/boost )"
+DEPEND=""
+
+
+Looks familar...right? It should since its going to look just like a regular
+ebuild.
+
+
+
+
+
+