Old-style 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 Optional Variables
• 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.

There are some things that are still only possible with old-style virtuals, which is why they are still useful:

• Packages providing the virtual can block the virtual, so you can ensure nothing else is installed that also provides that virtual.
• The ability to set a default in the profile for what the virtual should pull in (without the need of pulling the package into the system set).

New-style 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). One other difference (besides not installing any files) is that a new-style virtual has an empty string for the value of the LICENSE and HOMEPAGE variables. Since it installs no files, it really does not have a license.

An example of a new-style virtual:

DESCRIPTION="Virtual for C++ tr1 <type_traits>"
HOMEPAGE=""
SRC_URI=""
LICENSE=""
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.