doman Language Support

doman automatically detects language codes and puts it in the appropriate directory.

doman foo.1
# will go into /usr/share/man/man1/foo.1
doman foo.lang.1
# will go into /usr/share/man/lang/man1/foo.1 with EAPI="2"
		

Blocker Atoms

• New Meaning for Old Syntax

  Blocker atoms which use the previously existing !atom syntax now have a slightly different meaning. These blocker atoms indicate that conflicting packages may be temporarily installed simultaneously. When temporary simultaneous installation of conflicting packages occurs, the installation of a newer package may overwrite any colliding files that belong to an older package which is explicitly blocked. When such file collisions occur, the colliding files cease to belong to the older package, and they remain installed after the older package is eventually uninstalled. The older package is uninstalled only after any newer blocking packages have been merged on top of it.

• New !!atom Syntax

  A new !!atom syntax is now supported, for use in special cases for which temporary simultaneous installation of conflicting packages should not be allowed. If a given package happens to be blocked by a mixture of atoms consisting of both the !atom and !!atom syntaxes, the !!atom syntax takes precedence over the !atom syntax.

USE Dependencies

It is possible to depend on USE-flags of packages.

Examples:

• foo[bar] means that package foo must have USE-flag bar enabled
• foo[bar,baz] means that the package foo must have both the bar and baz USE-flags enabled
• foo[-bar,baz] means that the package foo must have the bar USE-flag disabled and baz USE-flag enabled
• foo[bar?] means bar? ( foo[bar] ) !bar? ( foo )
• foo[!bar?] means bar? ( foo ) !bar? ( foo[-bar] )
• foo[bar=] means bar? ( foo[bar] ) !bar? ( foo[-bar] )
• foo[!bar=] means bar? ( foo[-bar] ) !bar? ( foo[bar] )

Customization of Output File Names in SRC_URI

A new syntax is supported which allows customization of the output file name for a given URI. In order to customize the output file name, a given URI should be followed by a "->" operator which, in turn, should be followed by the desired output file name. As usual, all tokens, including the operator and output file name, should be separated by whitespace.

Example:

SRC_URI="http://dl.google.com/earth/client/GE4/release_4_3/GoogleEarthLinux.bin
                        -> GoogleEarthLinux-${PV}.bin"
		

New src_prepare Phase Function

A new src_prepare function is called after the src_unpack function, with cwd initially set to $S.

New src_configure Phase Function

The configure portion of the src_compile function has been split into a separate function which is named src_configure. The src_configure function is called in-between the src_prepare and src_compile functions.

The default src_configure and src_compile functions in EAPI=2:

src_configure() {
	if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
		econf
	fi
}

src_compile() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ] ; then
		emake || die "emake failed"
	fi
}
		

Execution Order of Phase Functions

• pkg_setup
• src_unpack
• src_prepare
• src_configure
• src_compile
• src_test
• src_install
• pkg_preinst
• pkg_postinst
• pkg_prerm
• pkg_postrm

Default Phase Functions

The default pkg_nofetch and src_* phase functions are now accessible via a function having a name that begins with default_ and ends with the respective phase function name. For example, a call to a function with the name default_src_compile is equivalent to a call to the default src_compile implementation.

The default phase functions are:

• default_pkg_nofetch
• default_src_unpack
• default_src_prepare
• default_src_configure
• default_src_compile
• default_src_test

Default Phase Function Alias

A function named "default" is redefined for each phase so that it will call the default_* function corresponding to the current phase. For example, a call to the function named "default" during the src_compile phase is equivalent to a call to the function named default_src_compile.

utilities die on their own, unless the nonfatal command is used

Ebuild functions all die on their own in EAPI=4. In case that this non-zero exit status is expected, you may call nonfatal function [arg,...].

Example:

EAPI=1
...
src_install() {
	emake DESTDIR="${D}" install || die "make install failed"
	dodoc ChangeLog README
}
		

EAPI=4
...
src_install() {
	emake DESTDIR="${D}" install
	nonfatal dodoc ChangeLog README
}
		

recursive dodoc

dodoc supports -r as the first argument, which leads dodoc to install the specified documentation directory recursively into the docdir.

Example:

src_install() {
	default
	dodoc ChangeLog
	dodoc -r doc/
}
		

doins symlink supports

Within EAPI=4, doins supports installing symlinks as symlinks when installing recursively. For older EAPIs, the symlink behaviour is undefined.

dosed and dohard are banned

The dosed and dohard commands are banned in this EAPI.

econf adds --disable-dependency-tracking

Within EAPI=4, econf adds --disable-dependency-tracking to the default configure options.

controllable compression via docompress

To compress files in the destination-folder ${D}, the docompress command may be used in src_install. To control which items should be compressed and which shouldn't be compressed, you may include or exclude directories or plain files. The default inclusion list contains:

• /usr/share/doc
• /usr/share/info
• /usr/share/man

• /usr/share/doc/${PF}/html

If the first argument of docompress is -x, the items specified will be added to the exclusion list, otherwise they will be added to the inclusion list.

use dependencies default

In addition to the use-deps specified in EAPI=2, a (+) or (-) may be added to the use-dep to define a default-value in case the use-flag does not exist in the given package. The (+) means that this use-flag is assumed to be enabled, (-) the opposite.

Example:

DEPEND="
	>=dev-libs/boost-1.32[boost(+)]
	sys-devel/gcc[openmp(-)]"
			

new pkg_pretend phase

The new pkg_pretend phase can be used to do sanity checks before the main phase function sequence is run (meaning this phase is executed after the package manager has calculated the dependencies and before installing them). This phase typically checks for a kernel configuration and may eerror and die when needed.

Example:

# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI="4"
inherit linux-info
...

CONFIG_CHECK="FUSE_FS"
ERROR_FUSE_FS="this is an unrealistic testcase..."

pkg_pretend() {
	if use kernel_linux ; then
		if [[ -e "${ROOT}"/usr/src/linux/.config ]] ; then
			if kernel_is lt 2 6 30 ; then
				check_extra_config
			fi
		fi
	fi
}
		

default src_install is no longer a no-op

The default src_install function in EAPI=4:

src_install() {
	if [[ -f Makefile ]] || [[ -f GNUmakefile]] || [[ -f makefile ]] ; then
		emake DESTDIR="${D}" install
	fi

	if ! declare -p DOCS >/dev/null 2>&1 ; then
		local d
		for d in README* ChangeLog AUTHORS NEWS TODO CHANGES THANKS BUGS \
				FAQ CREDITS CHANGELOG ; do
			[[ -s "${d}" ]] && dodoc "${d}"
		done
	# TODO: wrong "declare -a" command...
	elif declare -p DOCS | grep -q `^declare -a` ; then
		dodoc "${DOCS[@]}"
	else
		dodoc ${DOCS}
	fi
}
		

pkg_info for non-installed packages

The pkg_info function may also be called by the package manager for non-installed packages. Ebuild writers should note that dependencies may not be available.

REQUIRED_USE

The REQUIRED_USE variable contains a list of assertions that must be met by the configuration of USE flags to be valid for this ebuild. In order to be matched, a USE flag in a terminal element must be enabled (or disabled if it has an exclamation mark prefix).

Essentially, REQUIRED_USE is an analogue of DEPEND style syntax. For example, to state that some combination is forbidden, i.e. "if foo is set, bar must be unset":

REQUIRED_USE="foo? ( !bar )"
		

To state "if foo is set, then at least one of bar, baz, and quux must be activated":

REQUIRED_USE="foo? ( || ( bar baz quux ) )"
		

To state "exactly one of foo, bar, or baz must be set, but not several":

REQUIRED_USE="^^ ( foo bar baz )"
		

Note that the last relationship is that of an Exclusive OR (XOR). While an XOR could be formed from usual DEPEND syntax, a specific ^^ operator has been added for this case.

REPLACING_VERSIONS and REPLACED_BY_VERSION

The REPLACING_VERSIONS variable contains a whitespace-separated list of all versions (PVR) of this package that are being replaced (uninstalled or overwritten) as a result of this install. It is a list, not a single optional value, to handle pathological cases such as installing foo-2:2 to replace foo-2:1 and foo-3:2.

REPLACING_VERSIONS is valid in pkg_preinst and pkg_postinst. In addition, it may be available in pkg_pretend and pkg_setup, although you should take care to handle binary package creation and installation correctly when using it in these phases.

The REPLACED_BY variable contains the single version (PVR) of this package that is replacing us, if we are being uninstalled as part of an install, or an empty string otherwise. It is valid in pkg_prerm and pkg_postrm.

MERGE_TYPE

The MERGE_TYPE variable contains the type of package that is being merged. Possible values are:

source

if building and installing a package from source,

binary

if installing a binary package,

buildonly

if building a binary package without installing it.

AA and KV variables are gone

The AA and KV variables are no longer set in EAPI=4.

no more RDEPEND="${DEPEND}"

When RDEPEND is unset, there will no longer be an automatic assignment of RDEPEND="${DEPEND}".