\chapter{Old-Style Virtual Packages}
\label{old-virtuals}

Old-style virtuals are pseudo-packages---they can be depended upon or installed, but do not exist in
the ebuild repository.  An old-style virtual requires several things in the repository: at least one
ebuild must list the virtual in its \t{PROVIDE} variable, and there must be at least one entry in a
profiles \t{virtuals} file listing the default provider for each profile---see sections
\ref{ebuild-var-provide} and \ref{profiles-virtuals} for specifics on these two. Old-style virtuals
require special handling as regards dependencies; this is described below.

All old-style virtuals must use the category \t{virtual}. Not all packages using the \t{virtual}
category may be assumed to be old style virtuals.

\note A \i{new-style} virtual is simply an ebuild which install no files and use its dependency
strings to select providers. By convention, and to ease migration, these are also placed in the
\t{virtual} category.

\section{Dependencies on virtual packages}

When a dependency on a virtual package is encountered, it must be resolved into a real package
before it can be satisfied. There are two factors that affect this process: whether a package
providing the virtual is installed, and the \t{virtuals} file in the active profile (section
\ref{profiles-virtuals}). If a package is already installed which satisfies the virtual requirement
(via \t{PROVIDE}), then it should be used to satisfy the dependency. Otherwise, the profiles
\t{virtuals} file (section \ref{profiles-virtuals}) should be consulted to choose an appropriate
provider.

Dependencies on old style virtuals must not use any kind of version restriction.

Blocks on provided virtuals have special behaviour documented in section \ref{provided-blocks}.

% vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en :
