LinuxReviws.org --get your your Linux knowledge
> Linux Reviews > Manual Pages (man) >

ebuild


  1. ebuild.1.man
  2. ebuild.5.man


1. ebuild.1.man

Manpage of EBUILD

EBUILD

Section: Portage (1)
Updated: Feb 2011
Index Return to Main Contents
 

NAME

ebuild - a low level interface to the Portage system  

SYNOPSIS

ebuild file command [command]...  

DESCRIPTION

The ebuild program is a direct interface to the Portage system. It allows for direct action upon an ebuild with specific subcommands or groups of commands to perform in a specific ebuild's context and functions. Accepting an ebuild script and one or more commands as arguments, the ebuild program parses the ebuild script and executes the specified commands. Commands exist to fetch sources, unpack sources, compile sources, install object files into a temporary directory "image", merge the image to the local filesystem, create a bzipped tarball package out of the image, and more.  

FILE

This must be a valid ebuild script. For further information read ebuild(5).  

COMMANDS

By default, portage will execute all the functions in order up to the one actually specified. For example, simply issuing the command compile will trigger the functions before it to also be run (such as setup and unpack). If you wish to only have the specified command run, then you should use the noauto option in the FEATURES environment variable. See the make.conf(5) man page for more information.

help
Shows a condensed form of this man page along with a lot of package specific information.
setup
Runs all package-specific setup actions and exotic system checks.
clean
Cleans the temporary build directory that Portage has created for this particular ebuild file. The temporary build directory normally contains the extracted source files as well as a possible "install image" (all the files that will be merged to the local filesystem or stored in a package). The location of the build directory is set by the PORTAGE_TMPDIR variable. For information on what this variable is, run emerge --info, or to override this variable, see make.conf(5).

Note: Portage cleans up almost everything after a package has been successfully merged unless FEATURES contains 'noclean'. Adding noclean to FEATURES will cause a lot of files to remain and will consume large amounts of space, very quickly. It is not recommended to leave this on, unless you have use for the sources post-merge. Optionally, one may manually clean these files with rm -rf /var/tmp/portage.

fetch
Checks to see if all the sources specified in SRC_URI are available in DISTDIR (see make.conf(5) for more information) and have a valid md5 checksum. If the sources aren't available, an attempt is made to download them from the locations specified in SRC_URI. If multiple download locations are listed for a particular file, Portage pings each location to see which location is closer. (May not be true presently.) The Gentoo Linux mirrors defined by GENTOO_MIRRORS is always considered first. If for some reason the current or just-downloaded sources' md5 digests don't match those recorded in files/digest-[package]-[version-rev], a warning is printed and ebuild exits with an error code of 1.
digest
This is now equivalent to the manifest command.
manifest
Updates the manifest file for the package. This creates checksums for all of the files found in the same directory as the current ebuild as well as the recursive contents of the files subdirectory. It also creates checksums for all of the files listed in SRC_URI for each ebuild. For further information regarding the behavior of this command, see the documentation for the assume-digests value of the FEATURES variable in make.conf(5). See the --force option if you would like to prevent digests from being assumed.
unpack
Extracts the sources to a subdirectory in the build directory (BUILD_PREFIX) by running the src_unpack() function in the ebuild file. If no src_unpack() function has been specified, a default src_unpack() function is used that extracts all the files specified in SRC_URI. The sources are normally extracted to ${BUILD_PREFIX}/[package]-[version-rev]/work. This particular directory can be referenced by using the ${WORKDIR} variable.

If you're creating an ebuild, you'll want to make sure that the S (source directory) variable defined at the top of your ebuild script points to the directory that contains your extracted sources. This directory is defined by default to be ${WORKDIR}/${P}, so it is not often required. The src_unpack() function is also responsible for making the appropriate patches to the sources so that they're ready for compilation.

prepare
Prepares the extracted sources by running the src_prepare() function specified in the ebuild file. When src_prepare() starts, the current working directory will be set to ${S}. This function is supported beginning with EAPI 2.
configure
Configures the extracted sources by running the src_configure() function specified in the ebuild file. When src_configure() starts, the current working directory will be set to ${S}. This function is supported beginning with EAPI 2.
compile
Compiles the extracted sources by running the src_compile() function specified in the ebuild file. When src_compile() starts, the current working directory will be set to ${S}. When src_compile() completes, the sources should be fully compiled.
test
Runs package-specific test cases to verify that everything was built properly.
preinst
Runs package-specific actions that need to be done before the package is installed into the live filesystem.
install
Installs the package to the temporary install directory by running the src_install() function. When completed, the install directory (${BUILD_PREFIX}/[package]-[version-rev]/image) will contain all the files that should either be merged to the local filesystem or included in a binary package.
postinst
Runs package-specific actions that need to be done after the package is installed into the live filesystem. Usually helpful messages are shown here.
qmerge
This function installs all the files in the install directory to the live filesystem. The process works as follows: first, the pkg_preinst() function (if specified) is run. Then, the files are merged into the live filesystem, and the installed files' md5 digests are recorded in /var/db/pkg/${CATEGORY}/${PN}-${PVR}/CONTENTS. After all the files have been merged, the pkg_postinst() function (if specified) is executed.
merge
Normally, to merge an ebuild, you need to fetch, unpack, compile, install and qmerge. If you're simply interested in merging the ebuild, you can use this command, which will perform all these steps for you, stopping along the way if a particular step doesn't complete successfully.
unmerge
This function first executes the pkg_prerm() function (if specified). Then it removes all files from the live filesystem that have a valid md5 checksum and mtime in the package contents file. Any empty directories are recursively removed. Finally, it runs pkg_postrm() function (if specified). It is safe to merge a new version of a package first and then unmerge the old one. In fact, this is the recommended package upgrade method.
prerm
Runs package-specific actions that need to be executed before the package is removed from the filesystem. See also unmerge.
postrm
Runs package-specific actions that need to be executed after the package is removed from the filesystem. See also unmerge.
config
Runs package-specific actions that need to be executed after the emerge process has completed. This usually entails setup of configuration files or other similar setups that the user may wish to run.
package
This command is a lot like the merge command, except that after fetching, unpacking, compiling and installing, a .tbz2 binary package tarball is created and stored in PKGDIR (see make.conf(5)).
rpm
Builds a RedHat RPM package from the files in the temporary install directory. At the moment, the ebuild's dependency information is not incorporated into the RPM.
 

OPTIONS

--debug
Run bash with the -x option, causing it to output verbose debugging information to stdout.
--color < y | n >
Enable or disable color output. This option will override NOCOLOR (see make.conf(5)) and may also be used to force color output when stdout is not a tty (by default, color is disabled unless stdout is a tty).
--force
When used together with the digest or manifest command, this option forces regeneration of digests for all distfiles associated with the current ebuild. Any distfiles that do not already exist in ${DISTDIR} will be automatically fetched.
--ignore-default-opts
Do not use the EBUILD_DEFAULT_OPTS environment variable.
--skip-manifest
Skip all manifest checks.
 

REPORTING BUGS

Please report bugs via http://bugs.gentoo.org/  

AUTHORS

Achim Gottinger <achim@gentoo.org>
Daniel Robbins <drobbins@gentoo.org>
Nicholas Jones <carpaski@gentoo.org>
Mike Frysinger <vapier@gentoo.org>
 

FILES

/etc/make.conf
Contains variables for the build-process and overwrites those in make.globals.
/etc/portage/color.map
Contains variables customizing colors.
 

SEE ALSO

emerge(1), ebuild(5), make.conf(5), color.map(5)
The /usr/sbin/ebuild.sh script.
The helper apps in /usr/lib/portage/bin.


 

Index

NAME
SYNOPSIS
DESCRIPTION
FILE
COMMANDS
OPTIONS
REPORTING BUGS
AUTHORS
FILES
SEE ALSO

This document was created by man2html using the manual pages.
Time: 17:30:47 GMT, October 23, 2013

2. ebuild.5.man

Manpage of EBUILD

EBUILD

Section: Portage (5)
Updated: Dec 2011
Index Return to Main Contents
 

NAME

ebuild - the internal format, variables, and functions in an ebuild script  

DESCRIPTION

The ebuild(1) program accepts a single ebuild script as an argument. This script contains variables and commands that specify how to download, unpack, patch, compile, install and merge a particular software package from its original sources. In addition to all of this, the ebuild script can also contain pre/post install/remove commands, as required. All ebuild scripts are written in bash.  

EXAMPLES

Here's a simple example ebuild:

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

EAPI="4"

inherit some_eclass another_eclass

DESCRIPTION="Super-useful stream editor (sed)"
HOMEPAGE="http://www.gnu.org/software/sed/sed"
SRC_URI="ftp://alpha.gnu.org/pub/gnu/${PN}/${P}.tar.gz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86"
IUSE=""

RDEPEND=""
DEPEND="nls? ( sys-devel/gettext )"

src_configure() {
        econf \
                --bindir="${EPREFIX}"/bin
}

src_install() {
        emake DESTDIR="${D}" install
        dodoc NEWS README* THANKS AUTHORS BUGS ChangeLog
}
 

VARIABLES

MISC USAGE NOTES
- All variables defined in make.conf(5) are available for use in ebuilds (such as the PORTAGE* and PORTDIR* variables)
- When assigning values to variables in ebuilds, you cannot have a space between the variable name and the equal sign.
- Variable values should only contain characters that are members of the ascii(7) character set. This requirement is mandated by GLEP 31.
P
This variable contains the package name without the ebuild revision. This variable must NEVER be modified.
xfree-4.2.1-r2.ebuild --> $P=='xfree-4.2.1'
PN
Contains the name of the script without the version number.
xfree-4.2.1-r2.ebuild --> $PN=='xfree'
PV
Contains the version number without the revision.
xfree-4.2.1-r2.ebuild --> $PV=='4.2.1'
PR
Contains the revision number or 'r0' if no revision number exists.
xfree-4.2.1-r2.ebuild --> $PR=='r2'
PVR
Contains the version number with the revision.
xfree-4.2.1-r2.ebuild --> $PVR=='4.2.1-r2'
PF
Contains the full package name [PN]-[PVR]
xfree-4.2.1-r2.ebuild --> $PF=='xfree-4.2.1-r2'
CATEGORY
Contains the package category name.
A
Contains all source files required for the package. This variable must not be defined. It is autogenerated from the SRC_URI variable.
WORKDIR = "${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/work"
Contains the path to the package build root. Do not modify this variable.
FILESDIR = "${PORTDIR}/${CATEGORY}/${PN}/files"
Contains the path to the 'files' sub folder in the package specific location in the portage tree. Do not modify this variable.
EPREFIX
Beginning with EAPI 3, contains the offset that this Portage was configured for during installation. The offset is sometimes necessary in an ebuild or eclass, and is available in such cases as ${EPREFIX}. EPREFIX does not contain a trailing slash, therefore an absent offset is represented by the empty string. Do not modify this variable.
S = "${WORKDIR}/${P}"
Contains the path to the temporary build directory. This variable is used by the functions src_compile and src_install. Both are executed with S as the current directory. This variable may be modified to match the extraction directory of a tarball for the package.
T = "${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/temp"
Contains the path to a temporary directory. You may use this for whatever you like.
D = "${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/image/"
Contains the path to the temporary install directory. Every write operation that does not involve the helper tools and functions (found below) should be prefixed with ${D}. Beginning with EAPI 3, the offset prefix often needs to be taken into account here, for which the variable ${ED} is provided (see below). Do not modify this variable.
ED = "${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/image/${EPREFIX}/"
Beginning with EAPI 3, contains the path "${D%/}${EPREFIX}/" for convenience purposes. For EAPI values prior to EAPI 3 which do not support ${ED}, helpers use ${D} where they would otherwise use ${ED}. Do not modify this variable.
MERGE_TYPE
Beginning with EAPI 4, the MERGE_TYPE variable can be used to query the current merge type. This variable will contain one of the following possible values:

ValueMeaning


binarypreviously-built which is scheduled for merge
buildonlysource-build which is not scheduled for merge
sourcesource-build which is scheduled for merge
PORTAGE_LOG_FILE
Contains the path of the build log. If PORT_LOGDIR variable is unset then PORTAGE_LOG_FILE="${T}/build.log".
REPLACED_BY_VERSION
Beginning with EAPI 4, the REPLACED_BY_VERSION variable can be used in pkg_prerm and pkg_postrm to query the package version that is replacing the current package. If there is no replacement package, the variable will be empty, otherwise it will contain a single version number.
REPLACING_VERSIONS
Beginning with EAPI 4, the REPLACING_VERSIONS variable can be used in pkg_pretend, pkg_setup, pkg_preinst and pkg_postinst to query the package version(s) that the current package is replacing. If there are no packages to replace, the variable will be empty, otherwise it will contain a space-separated list of version numbers corresponding to the package version(s) being replaced. Typically, this variable will not contain more than one version, but according to PMS it can contain more.
ROOT = "/"
Contains the path that portage should use as the root of the live filesystem. When packages wish to make changes to the live filesystem, they should do so in the tree prefixed by ${ROOT}. Often the offset prefix needs to be taken into account here, for which the variable ${EROOT} is provided (see below). Do not modify this variable.
EROOT = "${ROOT%/}${EPREFIX}/"
Beginning with EAPI 3, contains "${ROOT%/}${EPREFIX}/" for convenience purposes. Do not modify this variable.
DESCRIPTION = "A happy little package"
Should contain a short description of the package.
EAPI = "0"
Defines the ebuild API version to which this package conforms. If not defined then it defaults to "0". If portage does not recognize the EAPI value then it will mask the package and refuse to perform any operations with it since this means that a newer version of portage needs to be installed first. For maximum backward compatiblity, a package should conform to the lowest possible EAPI. Note that anyone who uses the ebuild(1) and repoman(1) commands with this package will be required to have a version of portage that recognizes the EAPI to which this package conforms.
SRC_URI = "http://happy.com/little/${P}.tar.gz"
Contains a list of URIs for the required source files. It can contain multiple URIs for a single source file. The list is processed in order if the file was not found on any of the GENTOO_MIRRORS. Beginning with EAPI 2, the output file name of a given URI may be customized with a "->" operator on the right hand side, followed by the desired output file name. All tokens, including the operator and output file name, should be separated by whitespace.
HOMEPAGE = "http://happy.com/"
Should contain a list of URIs for the sources main sites and other further package dependent information.
KEYWORDS = [-~][x86,ppc,sparc,mips,alpha,arm,hppa]
Should contain appropriate list of arches that the ebuild is know to work/not work. By default if you do not know if an ebuild runs under a particular arch simply omit that KEYWORD. If the ebuild will not work on that arch include it as -ppc for example. If the ebuild is being submitted for inclusion, it must have ~arch set for architectures where it has been PROVEN TO WORK. (Packages KEYWORDed this way may be unmasked for testing by setting ACCEPT_KEYWORDS="~arch" on the command line, or in make.conf(5)) For an authoritative list please review /usr/portage/profiles/arch.list. Please keep this list in alphabetical order.
SLOT
This sets the SLOT for packages that may need to have multiple versions co-exist. By default you should set SLOT="0". If you are unsure, then do not fiddle with this until you seek some guidance from some guru. This value should NEVER be left undefined.
LICENSE
This should be a space delimited list of licenses that the package falls under. This _must_ be set to a matching license in /usr/portage/licenses/. If the license does not exist in portage yet, you must add it first.
IUSE
This should be a list of any and all USE flags that are leveraged within your build script. The only USE flags that should not be listed here are arch related flags (see KEYWORDS). Beginning with EAPI 1, it is possible to prefix flags with + or - in order to create default settings that respectively enable or disable the corresponding USE flags. For details about USE flag stacking order, refer to the USE_ORDER variable in make.conf(5). Given the default USE_ORDER setting, negative IUSE default settings are effective only for negation of repo-level USE settings, since profile and user configuration settings override them.
DEPEND
This should contain a list of all packages that are required for the program to compile.
DEPEND Atoms
A depend atom is simply a dependency that is used by portage when calculating relationships between packages. Please note that if the atom has not already been emerged, then the latest version available is matched.
Atom Bases
The base atom is just a full category/packagename. Hence, these are base atoms:

sys-apps/sed
sys-libs/zlib
net-misc/dhcp
Atom Versions
It is nice to be more specific and say that only certain versions of atoms are acceptable. Note that versions must be combined with a prefix (see below). Hence you may add a version number as a postfix to the base:

sys-apps/sed-4.0.5
sys-libs/zlib-1.1.4-r1
net-misc/dhcp-3.0_p2

Versions are normally made up of two or three numbers separated by periods, such as 1.2 or 4.5.2. This string may be followed by a character such as 1.2a or 4.5.2z. Note that this letter is not meant to indicate alpha, beta, etc... status. For that, use the optional suffix; either _alpha, _beta, _pre (pre-release), _rc (release candidate), or _p (patch). This means for the 3rd pre-release of a package, you would use something like 1.2_pre3. The suffixes here can be arbitrarily chained without limitation.

Atom Prefix Operators [> >= = <= <]
Sometimes you want to be able to depend on general versions rather than specifying exact versions all the time. Hence we provide standard boolean operators:

>media-libs/libgd-1.6
>=media-libs/libgd-1.6
=media-libs/libgd-1.6
<=media-libs/libgd-1.6
<media-libs/libgd-1.6
Extended Atom Prefixes [!~] and Postfixes [*]
Now to get even fancier, we provide the ability to define blocking packages and version range matching. Also note that these extended prefixes/postfixes may be combined in any way with the atom classes defined above. Here are some common examples you may find in the portage tree:

!app-text/dos2unix
=dev-libs/glib-2*
!=net-fs/samba-2*
~net-libs/libnet-1.0.2a
!!<sys-apps/portage-2.1.4_rc1

! means block packages from being installed at the same time.
!! means block packages from being installed at the same time and explicitly disallow them from being temporarily installed simultaneously during a series of upgrades. This syntax is supported beginning with EAPI 2.
* means match any version of the package so long as the specified string prefix is matched. So with a version of '2*', we can match '2.1', '2.2', '2.2.1', etc... and not match version '1.0', '3.0', '4.1', etc... Beware that, due to the string matching nature, '20' will also be matched by '2*'. The version part that comes before the '*' must be a valid version in the absence of the '*'. For example, '2' is a valid version and '2.' is not. Therefore, '2*' is allowed and '2.*' is not.
~ means match any revision of the base version specified. So in the above example, we would match versions '1.0.2a', '1.0.2a-r1', '1.0.2a-r2', etc...

Atom Slots
Beginning with EAPI 1, any atom can be constrained to match a specific SLOT. This is accomplished by appending a colon followed by a SLOT:

x11-libs/qt:3
~x11-libs/qt-3.3.8:3
>=x11-libs/qt-3.3.8:3
=x11-libs/qt-3.3*:3
Atom USE
Beginning with EAPI 2, any atom can be constrained to match specific USE flag settings. When used together with SLOT dependencies, USE dependencies appear on the right hand side of SLOT dependencies.

Unconditional USE Dependencies
ExampleMeaning


foo[bar]foo must have bar enabled
foo[bar,baz]foo must have both bar and baz enabled
foo[-bar,baz]foo must have bar disabled and baz enabled

Conditional USE Dependencies
Compact FormEquivalent Expanded Form


foo[bar?]bar? ( foo[bar] ) !bar? ( foo )
foo[!bar?]bar? ( foo ) !bar? ( foo[-bar] )
foo[bar=]bar? ( foo[bar] ) !bar? ( foo[-bar] )
foo[!bar=]bar? ( foo[-bar] ) !bar? ( foo[bar] )
Atom USE defaults
Beginning with EAPI 4, USE dependencies may specify default assumptions about values for flags that may or may not be missing from the IUSE of the matched package. Such defaults are specified by immediately following a flag with either (+) or (-). Use (+) to behave as if a missing flag is present and enabled, or (-) to behave as if it is present and disabled:

media-video/ffmpeg[threads(+)]
media-video/ffmpeg[threads(-)]
Dynamic DEPENDs
Sometimes programs may depend on different things depending on the USE variable. Portage offers a few options to handle this. Note that when using the following syntaxes, each case is considered as 1 Atom in the scope it appears. That means that each Atom both conditionally include multiple Atoms and be nested to an infinite depth.
usevar? ( DEPEND Atom )
To include the jpeg library when the user has jpeg in USE, simply use the following syntax:
jpeg? ( media-libs/jpeg )
!usevar? ( Atom )
If you want to include a package only if the user does not have a certain option in their USE variable, then use the following syntax:
!nophysfs? ( dev-games/physfs )
This is often useful for those times when you want to want to add optional support for a feature and have it enabled by default.
usevar? ( Atom if true ) !usevar? ( Atom if false )
For functionality like the tertiary operator found in C you must use two statements, one normal and one inverted. If a package uses GTK2 or GTK1, but not both, then you can handle that like this:
gtk2? ( =x11-libs/gtk+-2* ) !gtk2? ( =x11-libs/gtk+-1* )
That way the default is the superior GTK2 library.
|| ( Atom Atom ... )
When a package can work with a few different packages but a virtual is not appropriate, this syntax can easily be used.
|| (
app-games/unreal-tournament
app-games/unreal-tournament-goty
)
Here we see that unreal-tournament has a normal version and it has a goty version. Since they provide the same base set of files, another package can use either. Adding a virtual is inappropriate due to the small scope of it.
Another good example is when a package can be built with multiple video interfaces, but it can only ever have just one.
|| (
sdl? ( media-libs/libsdl )
svga? ( media-libs/svgalib )
opengl? ( virtual/opengl )
ggi? ( media-libs/libggi )
virtual/x11
)
Here only one of the packages will be chosen, and the order of preference is determined by the order in which they appear. So sdl has the best chance of being chosen, followed by svga, then opengl, then ggi, with a default of X if the user does not specify any of the previous choices.
Note that if any of the packages listed are already merged, the package manager will use that to consider the dependency satisfied.

RDEPEND
This should contain a list of all packages that are required for this program to run (aka runtime depend). If this is not set in EAPI 3 or earlier, then it defaults to the value of DEPEND. In EAPI 4 or later, RDEPEND will never be implicitly set.
You may use the same syntax to vary dependencies as seen above in DEPEND.
PDEPEND
This should contain a list of all packages that should be merged after this one, but may be merged before if need be.
You may use the same syntax to vary dependencies as seen above in DEPEND.
REQUIRED_USE
Beginning with EAPI 4, the REQUIRED_USE variable can be used to specify combinations of USE flags that are allowed or not allowed. Elements can be nested when necessary.
BehaviorExpression


If flag1 enabled then flag2 disabledflag1? ( !flag2 )
If flag1 enabled then flag2 disabledflag1? ( flag2 )
If flag1 disabled then flag2 enabled!flag1? ( flag2 )
If flag1 disabled then flag2 disabled!flag1? ( !flag2 )
Must enable any one or more (inclusive or)|| ( flag1 flag2 flag3 )
Must enable exactly one but not more (exclusive or)^^ ( flag1 flag2 flag3 )
RESTRICT = [strip,mirror,fetch,userpriv]
This should be a space delimited list of portage features to restrict. You may use conditional syntax to vary restrictions as seen above in DEPEND.
binchecks
Disable all QA checks for binaries. This should ONLY be used in packages for which binary checks make no sense (linux-headers and kernel-sources, for example, can safely be skipped since they have no binaries). If the binary checks need to be skipped for other reasons (such as proprietary binaries), see the QA CONTROL VARIABLES section for more specific exemptions.
bindist
Distribution of built packages is restricted.
fetch
like mirror but the files will not be fetched via SRC_URI either.
installsources
Disables installsources for specific packages. This is for packages with binaries that are not compatible with debugedit.
mirror
files in SRC_URI will not be downloaded from the GENTOO_MIRRORS.
primaryuri
fetch from URIs in SRC_URI before GENTOO_MIRRORS.
strip
final binaries/libraries will not be stripped of debug symbols.
test
do not run src_test even if user has FEATURES=test.
userpriv
Disables userpriv for specific packages.
PROPERTIES = [interactive]
A space delimited list of properties, with conditional syntax support.
interactive
One or more ebuild phases will produce a prompt that requires user interaction.
PROVIDE = "virtual/TARGET"
This variable should only be used when a package provides a virtual target. For example, blackdown-jdk and sun-jdk provide virtual/jdk. This allows for packages to depend on virtual/jdk rather than on blackdown or sun specifically.
DOCS
Beginning with EAPI 4, an array or space-delimited list of documentation files for the default src_install function to install using dodoc. If undefined, a reasonable default list is used. See the documentation for src_install below.
 

QA CONTROL VARIABLES

USAGE NOTES
Several QA variables are provided which allow an ebuild to manipulate some of the QA checks performed by portage. Use of these variables in ebuilds should be kept to an absolute minimum otherwise they defeat the purpose of the QA checks, and their use is subject to agreement of the QA team. They are primarily intended for use by ebuilds that install closed-source binary objects that cannot be altered.
Note that objects that violate these rules may fail on some architectures.
QA_PREBUILT
This should contain a list of file paths, relative to the image directory, of files that are pre-built binaries. Paths listed here will be appended to each of the QA_* variables listed below. The paths may contain fnmatch-like patterns which will be internally translated to regular expressions for the QA_* variables that support regular expressions instead of fnmatch patterns. The translation mechanism simply replaces "*" with ".*".
QA_TEXTRELS
This variable can be set to a list of file paths, relative to the image directory, of files that contain text relocations that cannot be eliminated. The paths may contain fnmatch patterns.
This variable is intended to be used on closed-source binary objects that cannot be altered.
QA_EXECSTACK
This should contain a list of file paths, relative to the image directory, of objects that require executable stack in order to run. The paths may contain fnmatch patterns.
This variable is intended to be used on objects that truly need executable stack (i.e. not those marked to need it which in fact do not).
QA_WX_LOAD
This should contain a list of file paths, relative to the image directory, of files that contain writable and executable segments. These are rare. The paths may contain fnmatch patterns.
QA_FLAGS_IGNORED
This should contain a list of file paths, relative to the image directory, of files that do not contain .GCC.command.line sections or contain .hash sections. The paths may contain regular expressions with escape-quoted special characters.
This variable is intended to be used on files of binary packages which ignore CFLAGS, CXXFLAGS, FFLAGS, FCFLAGS, and LDFLAGS variables.
QA_DT_HASH
This should contain a list of file paths, relative to the image directory, of files that contain .hash sections. The paths may contain regular expressions with escape-quoted special characters. This variable is deprecated. Use QA_FLAGS_IGNOREDinstead.
This variable is intended to be used on files of binary packages which ignore LDFLAGS variable.
QA_PRESTRIPPED
This should contain a list of file paths, relative to the image directory, of files that contain pre-stripped binaries. The paths may contain regular expressions with escape-quoted special characters.
QA_SONAME
This should contain a list of file paths, relative to the image directory, of shared libraries that lack SONAMEs. The paths may contain regular expressions with escape-quoted special characters.
QA_SONAME_NO_SYMLINK
This should contain a list of file paths, relative to the image directory, of shared libraries that have SONAMEs but should not have a corresponding SONAME symlink in the same directory. The paths may contain regular expressions with escape-quoted special characters.
QA_DT_NEEDED
This should contain a list of file paths, relative to the image directory, of shared libraries that lack NEEDED entries. The paths may contain regular expressions with escape-quoted special characters.
 

PORTAGE DECLARATIONS

inherit
Inherit is portage's maintenance of extra classes of functions that are external to ebuilds and provided as inheritable capabilities and data. They define functions and set data types as drop-in replacements, expanded, and simplified routines for extremely common tasks to streamline the build process. Call to inherit cannot depend on conditions which can vary in given ebuild. Specification of the eclasses contains only their name and not the .eclass extension. Also note that the inherit statement must come before other variable declarations unless these variables are used in global scope of eclasses.
 

PHASE FUNCTIONS

pkg_pretend
Beginning with EAPI 4, this function can be defined in order to check that miscellaneous requirements are met. It is called as early as possible, before any attempt is made to satisfy dependencies. If the function detects a problem then it should call eerror and die. The environment (variables, functions, temporary directories, etc..) that is used to execute pkg_pretend is not saved and therefore is not available in phases that execute afterwards.
pkg_nofetch
If you turn on fetch in RESTRICT, then this function will be run when the files in SRC_URI cannot be found. Useful for displaying information to the user on *how* to obtain said files. All you have to do is output a message and let the function return. Do not end the function with a call to die.
pkg_setup
This function can be used if the package needs specific setup actions or checks to be preformed before anything else.
Initial working directory of ${PORTAGE_TMPDIR}.
src_unpack
This function is used to unpack all the sources in A to WORKDIR. If not defined in the ebuild script it calls unpack ${A}. Any patches and other pre configure/compile modifications should be done here.
Initial working directory of $WORKDIR.
src_prepare
All preparation of source code, such as application of patches, should be done here. This function is supported beginning with EAPI 2.
Initial working directory of $S.
src_configure
All necessary steps for configuration should be done here. This function is supported beginning with EAPI 2.
Initial working directory of $S.
src_compile
With less than EAPI 2, all necessary steps for both configuration and compilation should be done here. Beginning with EAPI 2, only compilation steps should be done here.
Initial working directory of $S.
src_test
Run all package specific test cases. The default is to run 'make check' followed 'make test'.
Initial working directory of $S.
src_install
Should contain everything required to install the package in the temporary install directory.
Initial working directory of $S.

Beginning with EAPI 4, if src_install is undefined then the following default implementation is used:

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

    if ! declare -p DOCS &>/dev/null ; then
        local d
        for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
                THANKS BUGS FAQ CREDITS CHANGELOG ; do
            [[ -s "${d}" ]] && dodoc "${d}"
        done
    elif [[ $(declare -p DOCS) == "declare -a "* ]] ; then
        dodoc "${DOCS[@]}"
    else
        dodoc ${DOCS}
    fi
}
pkg_preinst pkg_postinst
All modifications required on the live-filesystem before and after the package is merged should be placed here. Also commentary for the user should be listed here as it will be displayed last.
Initial working directory of $PWD.
pkg_prerm pkg_postrm
Like the pkg_*inst functions but for unmerge.
Initial working directory of $PWD.
pkg_config
This function should contain optional basic configuration steps.
Initial working directory of $PWD.
 

HELPER FUNCTIONS: PHASES

default
Calls the default phase function implementation for the currently executing phase. This function is supported beginning with EAPI 2.
default_*
Beginning with EAPI 2, the default pkg_nofetch and src_* phase functions are 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.

Default Phase Functions

default_pkg_nofetch
default_src_unpack
default_src_prepare
default_src_configure
default_src_compile
default_src_test
 

HELPER FUNCTIONS: GENERAL

die [reason]
Causes the current emerge process to be aborted. The final display will include reason.

Beginning with EAPI 4, all helpers automatically call die whenever some sort of error occurs. Helper calls may be prefixed with the nonfatal helper in order to prevent errors from being fatal.

nonfatal <helper>
Execute helper and do not call die if it fails. The nonfatal helper is available beginning with EAPI 4.
use <USE item>
If USE item is in the USE variable, the function will silently return 0 (aka shell true). If USE item is not in the USE variable, the function will silently return 1 (aka shell false). usev is a verbose version of use.
Example:
if use gnome ; then
        guiconf="--enable-gui=gnome --with-x"
elif use gtk ; then
        guiconf="--enable-gui=gtk --with-x"
elif use X ; then
        guiconf="--enable-gui=athena --with-x"
else
        # No gui version will be built
        guiconf=""
fi
use_with <USE item> [configure name] [configure opt]
Useful for creating custom options to pass to a configure script. If USE item is in the USE variable and a configure opt is specified, then the string --with-[configure name]=[configure opt] will be echoed. If configure opt is not specified, then just --with-[configure name] will be echoed. If USE item is not in the USE variable, then the string --without-[configure name] will be echoed. If configure name is not specified, then USE item will be used in its place. Beginning with EAPI 4, an empty configure opt argument is recognized. In EAPI 3 and earlier, an empty configure opt argument is treated as if it weren't provided.
Examples:
USE="opengl"
myconf=$(use_with opengl)
(myconf now has the value "--with-opengl")

USE="jpeg"
myconf=$(use_with jpeg libjpeg)
(myconf now has the value "--with-libjpeg")

USE=""
myconf=$(use_with jpeg libjpeg)
(myconf now has the value "--without-libjpeg")

USE="sdl"
myconf=$(use_with sdl SDL all-plugins)
(myconf now has the value "--with-SDL=all-plugins")
use_enable <USE item> [configure name] [configure opt]
Same as use_with above, except that the configure options are --enable- instead of --with- and --disable- instead of --without-. Beginning with EAPI 4, an empty configure opt argument is recognized. In EAPI 3 and earlier, an empty configure opt argument is treated as if it weren't provided.
hasv <item> <item list>
If item is in item list, then item is echoed and hasv returns 0. Otherwise, nothing is echoed and 1 is returned. As indicated with use, there is a non-echoing version has. Please use has in all places where output is to be disregarded. Never use the output for calculation.
The item list is delimited by the IFS variable. This variable has a default value of ' ', or a space. It is a bash(1) setting.
has_version <category/package-version>
Check to see if category/package-version is installed on the system. The parameter accepts all values that are acceptable in the DEPEND variable. The function returns 0 if category/package-version is installed, 1 otherwise.
best_version <package name>
This function will look up package name in the database of currently installed programs and echo the "best version" of the package that is currently installed.
Example:
VERINS="$(best_version net-ftp/glftpd)"
(VERINS now has the value "net-ftp/glftpd-1.27" if glftpd-1.27 is installed)
 

HELPER FUNCTIONS: HOOKS

register_die_hook [list of function names]
Register one or more functions to call when the ebuild fails for any reason, including file collisions with other packages.
register_success_hook [list of function names]
Register one or more functions to call when the ebuild builds and/or installs successfully.
 

HELPER FUNCTIONS: OUTPUT

einfo "disposable message"
Same as elog, but should be used when the message isn't important to the user (like progress or status messages during the build process).
elog "informative message"
If you need to display a message that you wish the user to read and take notice of, then use elog. It works just like echo(1), but adds a little more to the output so as to catch the user's eye. The message will also be logged by portage for later review.
ewarn "warning message"
Same as einfo, but should be used when showing a warning to the user.
eqawarn "QA warning message"
Same as einfo, but should be used when showing a QA warning to the user.
eerror "error message"
Same as einfo, but should be used when showing an error to the user.
ebegin "helpful message"
Like einfo, we output a helpful message and then hint that the following operation may take some time to complete. Once the task is finished, you need to call eend.
eend <status> ["error message"]
Followup the ebegin message with an appropriate "OK" or "!!" (for errors) marker. If status is non-zero, then the additional error message is displayed.
 

HELPER FUNCTIONS: UNPACK

unpack <source> [list of more sources]
This function uncompresses and/or untars a list of sources into the current directory. The function will append source to the DISTDIR variable.
 

HELPER FUNCTIONS: COMPILE

econf [configure options]
This is used as a replacement for configure. Performs:
${ECONF_SOURCE:-.}/configure \
        ${CBUILD:+--build=${CBUILD}} \
        --datadir="${EPREFIX}"/usr/share \
        --host=${CHOST} \
        --infodir="${EPREFIX}"/usr/share/info \
        --localstatedir="${EPREFIX}"/var/lib \
        --prefix="${EPREFIX}"/usr \
        --mandir="${EPREFIX}"/usr/share/man \
        --sysconfdir="${EPREFIX}"/etc \
        ${CTARGET:+--target=${CTARGET}} \
        --disable-dependency-tracking \
        ${EXTRA_ECONF} \
        configure options || die "econf failed"
Note that the EXTRA_ECONF is for users only, not for ebuild writers. If you wish to pass more options to configure, just pass the extra arguments to econf. Also note that econf automatically calls die if the configure script fails. Beginning with EAPI 3, econf uses the ${EPREFIX} variable which is disregarded for prior EAPI values. Beginning with EAPI 4, econf adds --disable-dependency-tracking to the arguments if the string disable-dependency-tracking occurs in the output of configure --help.
emake [make options]
This is used as a replacement for make. Performs 'make ${MAKEOPTS} make options' (as set in make.globals), default is MAKEOPTS="-j2".

***warning***
if you are going to use emake, make sure your build is happy with parallel makes (make -j2). It should be tested thoroughly as parallel makes are notorious for failing _sometimes_ but not always. If you determine that your package fails to build in parallel, and you are unable to resolve the issue, then you should run 'emake -j1' instead of 'make'.

 

HELPER FUNCTIONS: INSTALL

einstall [make options]
This is used as a replacement for make install. Performs:
make \
        prefix=${ED}/usr \
        datadir=${ED}/usr/share \
        infodir=${ED}/usr/share/info \
        localstatedir=${ED}/var/lib \
        mandir=${ED}/usr/share/man \
        sysconfdir=${ED}/etc \
        ${EXTRA_EINSTALL} \
        make options \
        install
Please do not use this in place of 'emake install DESTDIR=${D}'. That is the preferred way of installing make-based packages. Also, do not utilize the EXTRA_EINSTALL variable since it is for users.

prepall
prepalldocs
prepallinfo
prepallman
prepallstrip
Useful for when a package installs into ${D} via scripts (i.e. makefiles). If you want to be sure that libraries are executable, aclocal files are installed into the right place, doc/info/man files are all compressed, and that executables are all stripped of debugging symbols, then use these suite of functions.
prepall:
Runs prepallman, prepallinfo, prepallstrip, sets libraries +x, and then checks aclocal directories. Please note this does *not* run prepalldocs.
prepalldocs:
Compresses all doc files in ${ED}/usr/share/doc.
prepallinfo:
Compresses all info files in ${ED}/usr/share/info.
prepallman:
Compresses all man files in ${ED}/usr/share/man.
prepallstrip:
Strips all executable files of debugging symboles. This includes libraries.

prepinfo [dir]
prepman [dir]
prepstrip [dir]
Similar to the prepall functions, these are subtle in their differences.
prepinfo:
If a dir is not specified, then prepinfo will assume the dir usr. prepinfo will then compress all the files in ${ED}/dir/info.
prepman:
If a dir is not specified, then prepman will assume the dir usr. prepman will then compress all the files in ${ED}/dir/man/*/.
prepstrip:
All the files found in ${ED}/dir will be stripped. You may specify multiple directories.
docompress [-x] <path> [list of more paths]
Beginning with EAPI 4, the docompress helper is used to manage lists of files to be included or excluded from optional compression. If the first argument is -x, add each of its subsequent arguments to the exclusion list. Otherwise, add each argument to the inclusion list. The inclusion list initially contains /usr/share/doc, /usr/share/info, and /usr/share/man. The exclusion list initially contains /usr/share/doc/${PF}.

The optional compression shall be carried out after src_install has completed, and before the execution of any subsequent phase function. For each item in the inclusion list, pretend it has the value of the D variable prepended, then:

If it is a directory, act as if every file or directory immediately under this directory were in the inclusion list.

If the item is a file, it may be compressed unless it has been excluded as described below.

If the item does not exist, it is ignored.

Whether an item is to be excluded is determined as follows: For each item in the exclusion list, pretend it has the value of the D variable prepended, then:

If it is a directory, act as if every file or directory immediately under this directory were in the exclusion list.

If the item is a file, it shall not be compressed.

If the item does not exist, it is ignored.

dosed "s:orig:change:g" <filename>
Beginning with EAPI 4, the dosed helper no longer exists. Ebuilds should call sed(1) directly (and assume that it is GNU sed).

Performs sed in place on filename inside ${ED}. If no expression is given then "s:${D}::g" is used as the default expression. Note that this expression does NOT use the offset prefix.
'dosed s:/usr/local:/usr:g /usr/bin/some-script' runs sed on ${ED}/usr/bin/some-script

dodir <path>
Creates a directory inside of ${ED}.
'dodir /usr/lib/apache' creates ${ED}/usr/lib/apache. Note that the do* functions will run dodir for you.
diropts [options for install(1)]
Can be used to define options for the install function used in dodir. The default is -m0755.
into <path>
Sets the root (DESTTREE) for other functions like dobin, dosbin, doman, doinfo, dolib.
The default root is /usr.
keepdir <path>
Tells portage to leave a directory behind even if it is empty. Functions the same as dodir.
dobin <binary> [list of more binaries]
Installs a binary or a list of binaries into DESTTREE/bin. Creates all necessary dirs.
dosbin <binary> [list of more binaries]
Installs a binary or a list of binaries into DESTTREE/sbin. Creates all necessary dirs.
doinitd <init.d script> [list of more init.d scripts]
Install Gentoo init.d scripts. They will be installed into the correct location for Gentoo init.d scripts (/etc/init.d/). Creates all necessary dirs.
doconfd <conf.d file> [list of more conf.d file]
Install Gentoo conf.d files. They will be installed into the correct location for Gentoo conf.d files (/etc/conf.d/). Creates all necessary dirs.
doenvd <env.d entry> [list of more env.d entries]
Install Gentoo env.d entries. They will be installed into the correct location for Gentoo env.d entries (/etc/env.d/). Creates all necessary dirs.

dolib <library> [list of more libraries]
dolib.a <library> [list of more libraries]
dolib.so <library> [list of more libraries]
Installs a library or a list of libraries into DESTTREE/lib. Creates all necessary dirs.
libopts [options for install(1)]
Can be used to define options for the install function used in the dolib functions. The default is -m0644.
doman [-i18n=<locale>] <man-page> [list of more man-pages]
Installs manual-pages into /usr/share/man/man[0-9n] depending on the manual file ending. The files are compressed if they are not already. You can specify locale-specific manpages with the -i18n option. Then the man-page will be installed into /usr/share/man/<locale>/man[0-9n]. Beginning with EAPI 2, a locale-specific manpage which contains a locale in the file name will be installed in /usr/share/man/<locale>/man[0-9n], with the locale portion of the file name removed, and the -i18n option has no effect. For example, with EAPI 2, a manpage named foo.<locale>.1 will be installed as /usr/share/man/<locale>EAPI 4, the -i18n option takes precedence over the locale suffix of the file name.
dohard <filename> <linkname>
Beginning with EAPI 4, the dohard helper no longer exists. Ebuilds should call ln(1) directly.
dosym <filename> <linkname>
Performs the ln command to create a symlink.
d [-a filetypes] [-r] [-x list-of-dirs-to-ignore] [list-of-files-and-dirs]
Installs the files in the list of files (space-separated list) into /usr/share/doc/${PF} provided the file ends in .htm, , .css, .js, .gif, .jpeg, .jpg, or .png. Setting -a limits what types of files will be included, -A appends to the default list, setting -x sets which dirs to exclude (CVS excluded by default), -p sets a document prefix, -r sets recursive.
doinfo <info-file> [list of more info-files]
Installs info-pages into DESTDIR/info. Files are automatically gzipped. Creates all necessary dirs.
domo <locale-file> [list of more locale-files]
Installs locale-files into DESTDIR/usr/share/locale/[LANG] depending on local-file's ending. Creates all necessary dirs.

fowners <permissions> <file> [files]
fperms <permissions> <file> [files]
Performs chown (fowners) or chmod (fperms), applying permissions to files.
insinto [path]
Sets the destination path for the doins function.
The default path is /.
insopts [options for install(1)]
Can be used to define options for the install function used in doins. The default is -m0644.
doins [-r] <file> [list of more files]
Installs files into the path controlled by insinto. This function uses install(1). Creates all necessary dirs. Setting -r sets recursive. Beginning with EAPI 4, both doins and newins preserve symlinks. In EAPI 3 and earlier, symlinks are dereferenced rather than preserved.
exeinto [path]
Sets the destination path for the doexe function.
The default path is /.
exeopts [options for install(1)]
Can be used to define options for the install function used in doexe. The default is -m0755.
doexe <executable> [list of more executables]
Installs executables into the path controlled by exeinto. This function uses install(1). Creates all necessary dirs.
docinto [path]
Sets the subdir used by dodoc and d when installing into the document tree (based in /usr/share/doc/${PF}/). Default is no subdir, or just "".
dodoc [-r] <document> [list of more documents]
Installs a document or a list of documents into /usr/share/doc/${PF}/<docinto path>. Documents are marked for compression. Creates all necessary dirs. Beginning with EAPI 4, there is support for recursion, enabled by the new -r option.

newbin <old file> <new filename>
newsbin <old file> <new filename>
newinitd <old file> <new filename>
newconfd <old file> <new filename>
newenvd <old file> <new filename>
newlib.so <old file> <new filename>
newlib.a <old file> <new filename>
newman <old file> <new filename>
newinfo <old file> <new filename>
newins <old file> <new filename>
newexe <old file> <new filename>
newdoc <old file> <new filename>
All these functions act like the do* functions, but they only work with one file and the file is installed as [new filename].
 

REPORTING BUGS

Please report bugs via http://bugs.gentoo.org/  

AUTHORS

Achim Gottinger <achim@gentoo.org>
Mark Guertin <gerk@gentoo.org>
Nicholas Jones <carpaski@gentoo.org>
Mike Frysinger <vapier@gentoo.org>
Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA@gmail.com>
Fabian Groffen <grobian@gentoo.org>
 

FILES

The /usr/sbin/ebuild.sh script.
The helper apps in /usr/lib/portage/bin.
/etc/make.conf
Contains variables for the build-process and overwrites those in make.defaults.
/usr/share/portage/config/make.globals
Contains the default variables for the build-process, you should edit /etc/make.conf instead.
/etc/portage/color.map
Contains variables customizing colors.
 

SEE ALSO

ebuild(1), make.conf(5), color.map(5)


 

Index

NAME
DESCRIPTION
EXAMPLES
VARIABLES
QA CONTROL VARIABLES
PORTAGE DECLARATIONS
PHASE FUNCTIONS
HELPER FUNCTIONS: PHASES
HELPER FUNCTIONS: GENERAL
HELPER FUNCTIONS: HOOKS
HELPER FUNCTIONS: OUTPUT
HELPER FUNCTIONS: UNPACK
HELPER FUNCTIONS: COMPILE
HELPER FUNCTIONS: INSTALL
REPORTING BUGS
AUTHORS
FILES
SEE ALSO

This document was created by man2html using the manual pages.
Time: 17:30:47 GMT, October 23, 2013

ja - pl

Meet new people