Automatic dependency resolution is one of the most useful features provided by
DEPEND ebuild variable should specify any dependencies which are
required to unpack, patch, compile or install the package (but see
Implicit System Dependency for
RDEPEND ebuild variable should specify any dependencies which are
required at runtime. This includes libraries (when dynamically linked), any data
packages and (for interpreted languages) the relevant interpreter. In EAPI=3 or
older, if this variable is not specified it defaults to the value of
DEPEND, however the implicit usage is frowned upon. In EAPI=4, the
implicit behaviour was removed and the assignment is always explicit.
Note that when installing from a binary package, only
RDEPEND will be
checked. It is therefore necessary to include items even if they are also listed
Items which are in
RDEPEND but not
DEPEND could in theory be merged
after the target package. Portage does not currently do this.
PDEPEND variable specifies dependencies that should be
merged after the package, but which may be merged at any time,
if the former is not possible. This is sometimes used for plugins
that have a dependency upon the package being merged. Generally
PDEPEND should be avoided in favour of
where this will create circular dependency chains.
All packages have an implicit compile-time and runtime dependency upon the
system target. It is therefore not necessary, nor advisable, to
specify dependencies upon toolchain packages like
so on, except where specific versions or packages (for example,
uclibc) are required. Note that this rule also needs consideration
for packages like
libtool, which aren't in
system target for every profile. For example, the embedded profile
system target, the
libtool ABI might
change and break building order and
flex might get removed from the
system target in future.
However, packages which are included in the
system target, or are
system target packages, should generally include a complete
dependency list (excluding bootstrap packages). This makes
emerge -e system
possible when installing from a stage 1 or stage 2 tarball.
DEPEND specification might look like the following:
DEPEND="dev-lang/ruby dev-ruby/ruby-gtk2 dev-ruby/mysql-ruby"
Each atom is the full category and name of a package. Atoms are separated by arbitrary whitespace — convention is to specify one atom per line for readability purposes. When specifying names, the category part should be treated as mandatory.
Sometimes a particular version of a package is needed. Where this is known, it should be specified. A simple example:
This states that at least version 0.9.7d of
openssl is required.
Available version specifiers are:
||Version 1.23 or later is required.|
||A version strictly later than 1.23 is required.|
||Version 1.23 (or any
Exactly version 1.23 is required. If at all possible,
||Version 1.23 or older is required.|
||A version strictly before 1.23 is required.|
To specify "version 2.x (not 1.x or 3.x)" of a package, it is necessary to use the asterisk postfix. This is most commonly seen in situations like:
DEPEND="gtk? ( =x11-libs/gtk+-1.2* )"
Note that the equals sign is mandatory, and that there is no dot before the
asterisk. Also note that when selecting all versions in a specific
SLOT dependencies should be used (see below).
Sometimes two packages cannot be installed in parallel. This is handled by blockers. A softblocker is specified as follows:
Portage will try to resolve this conflict automatically if possible. Sometimes we need to use a hardblocker to ensure correct emerge order. Those cannot be resolved by Portage and must be taken care of by the user. A hardblocker is specified as follows:
Hardblockers always take precedence over softblockers and need at least EAPI="2". Also note that blockers are usually runtime rather than buildtime.
Specific versions can also be blocked:
Blockers can be optional based upon
USE flags as per normal
Blockers added to older ebuilds should not be expected to be retroactive. If the user already has the ebuild installed, any changes to the ebuild should not be expected to make any difference. This means that you should add the blockers to whichever ebuild is the newest (even if it means that logically it would seem backwards). For example, certain versions of portage don't like some versions of bash, but the blocker was put into bash because that was the newer package that caused the issues.
In order to depend on a package in a specific
SLOT you must specify
To depend on a specific
:SLOT should be appended to
the package name, where 'SLOT' is the
SLOT of the package wanted:
DEPEND="qt3? ( x11-libs/qt:3 ) gtk? ( x11-libs/gtk+:2 )
To depend on a specific version or version-range within a SLOT we use:
DEPEND="qt3? ( ~x11-libs/qt-3.3.8:3 ) gtk? ( >=x11-libs/gtk+-2.24.9:2 )
EAPI="5" and higher, you can use slot operators appended to the package
name to declare whether or not your package should be rebuilt after the versions
satisfying its runtime dependencies are updated to versions with a different slot
:=means that any slot is acceptable, and that your package should be rebuilt if the version best matching the runtime dependency is updated to a version with a different slot or subslot;
:*means that any slot is acceptable, and explicitly declares that changes in the slot or sub-slot can be ignored;
:SLOT=means that only the 'SLOT' slot is acceptable, and that your package should be rebuilt if the version matching the runtime dependency is updated to another version with this slot but with a different subslot;
:SLOTmeans that only the 'SLOT' slot is acceptable, and that changes in the sub-slot can be ignored (like in previous EAPIs).
:SLOT/SUBSLOTmeans a dependency on a specific slot and sub-slot pair, which can be useful for packages installing pre-built binaries that require a library with a particular soname version corresponding to the sub-slot.
RDEPEND="media-libs/cogl:1.0= gnutls? ( >=net-libs/gnutls-2.8:= )"
To depend upon a certain package if and only if a given
USE flag is set:
DEPEND="perl? ( dev-lang/perl ) ruby? ( >=dev-lang/ruby-1.8 ) python? ( dev-lang/python )"
It is also possible to depend upon a certain package if a given
USE flag is
RDEPEND="!crypt? ( net-misc/netkit-rsh )"
This should not be used for disabling a certain
USE flag on a given
architecture. In order to do this, the architecture team should add the
flag to their
use.mask file in the
directory of the Portage tree.
This can be nested:
DEPEND="!build? ( gcj? ( gtk? ( x11-libs/libXt x11-libs/libX11 x11-libs/libXtst x11-proto/xproto x11-proto/xextproto >=x11-libs/gtk+-2.2 x11-libs/pango ) >=media-libs/libart_lgpl-2.1 ) >=sys-libs/ncurses-5.2-r2 nls? ( sys-devel/gettext ) )"
To depend on either
DEPEND="|| ( app-misc/foo app-misc/bar )"
To depend on either
bar if the
USE flag is set:
DEPEND="baz? ( || ( app-misc/foo app-misc/bar ) )"
fnord can be built against either
bar. Then a
flag is not necessary if and only if all of the following hold:
fnordis merged on a system which has
foois then unmerged, and
fnordmust continue to work correctly.
fnordmade on a system with
barcan be taken and installed on a system with
In order to use built with use dependencies you must specify
Available specifiers are:
||foo must have bar enabled.|
||foo must have both bar and baz enabled.|
||foo must have bar disabled and baz enabled.|
There are also shortcuts for conditional situations:
|Compact form||Equivalent expanded form|
If a dependency is introducing or removing a
USE flag in new versions, a use
dependency default may be used. Appending a
(-) suffix will indicate
whether the absence of the flag from a particular version should indicate its
presence or absence.
>=dev-libs/boost-1.48[threads(+)] will treat all versions without
threads as having it set.
Once upon a time the
: conditional operator was allowed in
DEPEND="use-flag? ( app-misc/foo ) : ( app-misc/bar )"
This syntax is no longer permitted. It is exactly equivalent to the following, which should be used instead:
DEPEND="use-flag? ( app-misc/foo ) !use-flag? ( app-misc/bar )"
It is useful to recognise the legacy syntax and to know that it is no longer valid.