\chapter{Ebuild-defined Functions} \label{sec:ebuild-functions} \section{List of Functions} \label{sec:functions} The following is a list of functions that an ebuild, or eclass, may define, and which will be called by the package manager as part of the build and/or install process. In all cases the package manager must provide a default implementation of these functions; unless otherwise stated this must be a no-op. Most functions must assume only that they have write access to the package's working directory (the \t{WORKDIR} environment variable; see section~\ref{env-var-WORKDIR}), and the temporary directory \t{T}; exceptions are noted below. All functions may assume that they have read access to all system libraries, binaries and configuration files that are accessible to normal users. The environment for functions run outside of the build sequence (that is, \t{pkg\_config}, \t{pkg\_info}, \t{pkg\_prerm} and \t{pkg\_postrm}) must be the environment used for the build of the package, not the current configuration. Ebuilds must not call nor assume the existence of any phase functions. \subsection{Initial Working Directories} \label{sec:s-to-workdir-fallback} Some functions may assume that their initial working directory is set to a particular location; these are noted below. If no initial working directory is mandated, it may be set to anything and the ebuild must not rely upon a particular location for it. The ebuild \e{may} assume that the initial working directory for any phase is a trusted location that may only be written to by a privileged user and group. \featurelabel{s-workdir-fallback} Some functions are described as having an initial working directory of \t{S} with an error or fallback to \t{WORKDIR}\@. For EAPIs listed in table~\ref{tab:s-fallback-table} as having the fallback, this means that if \t{S} is not a directory before the start of the phase function, the initial working directory shall be \t{WORKDIR} instead. For EAPIs where it is a conditional error, if \t{S} is not a directory before the start of the phase function, it is a fatal error, unless all of the following conditions are true, in which case the fallback to \t{WORKDIR} is used: \begin{compactitem} \item The \t{A} variable contains no items. \item The phase function in question is not in \t{DEFINED\_PHASES}. \item None of the phase functions \t{unpack}, \t{prepare}, \t{configure}, \t{compile} or \t{install}, if supported by the EAPI in question and occurring prior to the phase about to be executed, are in \t{DEFINED\_PHASES}. \end{compactitem} \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs with \t{S} to \t{WORKDIR} fallbacks} \label{tab:s-fallback-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Fallback to \t{WORKDIR} permitted?}} \\ \midrule \t{0} & Always \\ \t{1} & Always \\ \t{2} & Always \\ \t{3} & Always \\ \t{4} & Conditional error \\ \t{5} & Conditional error \\ \bottomrule \end{tabular} \end{centertable} \subsection{pkg\_pretend} \label{sec:pkg-pretend-function} \featurelabel{pkg-pretend} The \t{pkg\_pretend} function is only called for EAPIs listed in table~\ref{tab:pkg-pretend-table} as supporting it. The \t{pkg\_pretend} function may be used to carry out sanity checks early on in the install process. For example, if an ebuild requires a particular kernel configuration, it may perform that check in \t{pkg\_pretend} and call \t{eerror} and then \t{die} with appropriate messages if the requirement is not met. \t{pkg\_pretend} is run separately from the main phase function sequence, and does not participate in any kind of environment saving. There is no guarantee that any of an ebuild's dependencies will be met at this stage, and no guarantee that the system state will not have changed substantially before the next phase is executed. \t{pkg\_pretend} must not write to the filesystem. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs supporting \t{pkg\_pretend}} \label{tab:pkg-pretend-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports \t{pkg\_pretend}?}} \\ \midrule \t{0} & No \\ \t{1} & No \\ \t{2} & No \\ \t{3} & No \\ \t{4} & Yes \\ \t{5} & Yes \\ \bottomrule \end{tabular} \end{centertable} \subsection{pkg\_setup} \label{sec:pkg-setup-function} The \t{pkg\_setup} function sets up the ebuild's environment for all following functions, before the build process starts. Further, it checks whether any necessary prerequisites not covered by the package manager, e.\,g.\ that certain kernel configuration options are fulfilled. \t{pkg\_setup} must be run with full filesystem permissions, including the ability to add new users and/or groups to the system. \subsection{src\_unpack} \label{sec:src-unpack-function} \featurelabel{src-unpack} The \t{src\_unpack} function extracts all of the package's sources. In EAPIs lacking \t{src\_prepare}, it may also apply patches and set up the package's build system for further use. The initial working directory must be \t{WORKDIR}, and the default implementation used when the ebuild lacks the \t{src\_unpack} function shall behave as: \begin{verbatim} src_unpack() { if [[ -n ${A} ]]; then unpack ${A} fi } \end{verbatim} \subsection{src\_prepare} \label{sec:src-prepare-function} \featurelabel{src-prepare} The \t{src\_prepare} function is only called for EAPIs listed in table~\ref{tab:src-prepare-table} as supporting it. The \t{src\_prepare} function can be used for post-unpack source preparation. The default implementation does nothing. The initial working directory is \t{S}, with an error or fallback to \t{WORKDIR} as discussed in section~\ref{sec:s-to-workdir-fallback}. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs supporting \t{src\_prepare}} \label{tab:src-prepare-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports \t{src\_prepare}?}} \\ \midrule \t{0} & No \\ \t{1} & No \\ \t{2} & Yes \\ \t{3} & Yes \\ \t{4} & Yes \\ \t{5} & Yes \\ \bottomrule \end{tabular} \end{centertable} \subsection{src\_configure} \label{sec:src-configure-function} \featurelabel{src-configure} The \t{src\_configure} function is only called for EAPIs listed in table~\ref{tab:src-configure-table} as supporting it. The initial working directory is \t{S}, with an error or fallback to \t{WORKDIR} as discussed in section~\ref{sec:s-to-workdir-fallback}. The \t{src\_configure} function configures the package's build environment. The default implementation used when the ebuild lacks the \t{src\_configure} function shall behave as: \begin{verbatim} src_configure() { if [[ -x ${ECONF_SOURCE:-.}/configure ]]; then econf fi } \end{verbatim} \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs supporting \t{src\_configure}} \label{tab:src-configure-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports \t{src\_configure}?}} \\ \midrule \t{0} & No \\ \t{1} & No \\ \t{2} & Yes \\ \t{3} & Yes \\ \t{4} & Yes \\ \t{5} & Yes \\ \bottomrule \end{tabular} \end{centertable} \subsection{src\_compile} \label{sec:src-compile-function} \featurelabel{src-compile} The \t{src\_compile} function configures the package's build environment in EAPIs lacking \t{src\_configure}, and builds the package in all EAPIs. The initial working directory is \t{S}, with an error or fallback to \t{WORKDIR} as discussed in section~\ref{sec:s-to-workdir-fallback}. \featurelabel{src-compile-0} For EAPIs listed in table~\ref{tab:src-compile-table} as using format 0, the default implementation used when the ebuild lacks the \t{src\_compile} function shall behave as: \begin{verbatim} src_compile() { if [[ -x ./configure ]]; then econf fi if [[ -f Makefile ]] || [[ -f GNUmakefile ]] || [[ -f makefile ]]; then emake || die "emake failed" fi } \end{verbatim} \featurelabel{src-compile-1} For EAPIs listed in table~\ref{tab:src-compile-table} as using format 1, the default implementation used when the ebuild lacks the \t{src\_compile} function shall behave as: \begin{verbatim} src_compile() { if [[ -x ${ECONF_SOURCE:-.}/configure ]]; then econf fi if [[ -f Makefile ]] || [[ -f GNUmakefile ]] || [[ -f makefile ]]; then emake || die "emake failed" fi } \end{verbatim} \featurelabel{src-compile-2} For EAPIs listed in table~\ref{tab:src-compile-table} as using format 2, the default implementation used when the ebuild lacks the \t{src\_compile} function shall behave as: \begin{verbatim} src_compile() { if [[ -f Makefile ]] || [[ -f GNUmakefile ]] || [[ -f makefile ]]; then emake || die "emake failed" fi } \end{verbatim} \ChangeWhenAddingAnEAPI{5} \begin{centertable}{\t{src\_compile} behaviour for EAPIs} \label{tab:src-compile-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Format}} \\ \midrule \t{0} & 0 \\ \t{1} & 1 \\ \t{2} & 2 \\ \t{3} & 2 \\ \t{4} & 2 \\ \t{5} & 2 \\ \bottomrule \end{tabular} \end{centertable} \subsection{src\_test} \label{sec:src-test-function} The \t{src\_test} function runs unit tests for the newly built but not yet installed package as provided. The initial working directory must be \t{S} if that exists, falling back to \t{WORKDIR} otherwise. The default implementation used when the ebuild lacks the \t{src\_test} function must, if tests are enabled, run \t{emake check} if and only if such a target is available, or if not run \t{emake test} if and only if such a target is available. In both cases, if \t{emake} returns non-zero the build must be aborted. \featurelabel{parallel-tests} For EAPIs listed in table~\ref{tab:src-test-table} as not supporting parallel tests, the \t{emake} command must be called with option \t{-j1}. The \t{src\_test} function may be disabled by \t{RESTRICT}\@. See section~\ref{sec:restrict}. It may be disabled by user too, using a PM-specific mechanism. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{\t{src\_test} behaviour for EAPIs} \label{tab:src-test-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports parallel tests?}} \\ \midrule \t{0} & No \\ \t{1} & No \\ \t{2} & No \\ \t{3} & No \\ \t{4} & No \\ \t{5} & Yes \\ \bottomrule \end{tabular} \end{centertable} \subsection{src\_install} \label{sec:src-install-function} \featurelabel{src-install} The \t{src\_install} function installs the package's content to a directory specified in \t{D}. The initial working directory is \t{S}, with an error or fallback to \t{WORKDIR} as discussed in section~\ref{sec:s-to-workdir-fallback}. \featurelabel{src-install-4} For EAPIs listed in table~\ref{tab:src-install-table} as using format 4, the default implementation used when the ebuild lacks the \t{src\_install} function shall behave as: \begin{verbatim} 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 elif declare -p DOCS | grep -q "^declare -a " ; then dodoc "${DOCS[@]}" else dodoc ${DOCS} fi } \end{verbatim} For other EAPIs, the default implementation used when the ebuild lacks the \t{src\_install} function is a no-op. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{\t{src\_install} behaviour for EAPIs} \label{tab:src-install-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Format}} \\ \midrule \t{0} & no-op \\ \t{1} & no-op \\ \t{2} & no-op \\ \t{3} & no-op \\ \t{4} & 4 \\ \t{5} & 4 \\ \bottomrule \end{tabular} \end{centertable} \subsection{pkg\_preinst} \label{sec:pkg-preinst-function} The \t{pkg\_preinst} function performs any special tasks that are required immediately before merging the package to the live filesystem. It must not write outside of the directories specified by the \t{ROOT} and \t{D} environment variables. \t{pkg\_preinst} must be run with full access to all files and directories below that specified by the \t{ROOT} and \t{D} environment variables. \subsection{pkg\_postinst} \label{sec:pkg-postinst-function} The \t{pkg\_postinst} function performs any special tasks that are required immediately after merging the package to the live filesystem. It must not write outside of the directory specified in the \t{ROOT} environment variable. \t{pkg\_postinst}, like, \t{pkg\_preinst}, must be run with full access to all files and directories below that specified by the \t{ROOT} environment variable. \subsection{pkg\_prerm} \label{sec:pkg-prerm-function} The \t{pkg\_prerm} function performs any special tasks that are required immediately before unmerging the package from the live filesystem. It must not write outside of the directory specified by the \t{ROOT} environment variable. \t{pkg\_prerm} must be run with full access to all files and directories below that specified by the \t{ROOT} environment variable. \subsection{pkg\_postrm} \label{sec:pkg-postrm-function} The \t{pkg\_postrm} function performs any special tasks that are required immediately after unmerging the package from the live filesystem. It must not write outside of the directory specified by the \t{ROOT} environment variable. \t{pkg\_postrm} must be run with full access to all files and directories below that specified by the \t{ROOT} environment variable. \subsection{pkg\_config} \label{sec:pkg-config-function} The \t{pkg\_config} function performs any custom steps required to configure a package after it has been fully installed. It is the only ebuild function which may be interactive and prompt for user input. \t{pkg\_config} must be run with full access to all files and directories inside of \t{ROOT}. \subsection{pkg\_info} \label{sec:pkg-info-function} \featurelabel{pkg-info} The \t{pkg\_info} function may be called by the package manager when displaying information about an installed package. In EAPIs listed in table~\ref{tab:pkg-info-table} as supporting \t{pkg\_info} on non-installed packages, it may also be called by the package manager when displaying information about a non-installed package. In this case, ebuild authors should note that dependencies may not be installed. \t{pkg\_info} must not write to the filesystem. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs supporting \t{pkg\_info} on non-installed packages} \label{tab:pkg-info-table} \begin{tabular}{ l l } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports \t{pkg\_info} on non-installed packages?}} \\ \midrule \t{0} & No \\ \t{1} & No \\ \t{2} & No \\ \t{3} & No \\ \t{4} & Yes \\ \t{5} & Yes \\ \bottomrule \end{tabular} \end{centertable} \subsection{pkg\_nofetch} \label{sec:pkg-nofetch-function} The \t{pkg\_nofetch} function is run when the fetch phase of an fetch-restricted ebuild is run, and the relevant source files are not available. It should direct the user to download all relevant source files from their respective locations, with notes concerning licensing if applicable. \t{pkg\_nofetch} must require no write access to any part of the filesystem. \subsection{\t{default\_} Phase Functions} \label{sec:default-phase-funcs} \featurelabel{default-phase-funcs} In EAPIs listed in table~\ref{tab:default-phase-function-table} as supporting \t{default\_} phase functions, a function named \t{default\_}(phase) that behaves as the default implementation for that EAPI shall be defined when executing any ebuild phase listed in the table. Ebuilds must not call these functions except when in the phase in question. \ChangeWhenAddingAnEAPI{5} \begin{centertable}{EAPIs supporting \t{default\_} phase functions} \label{tab:default-phase-function-table} \begin{tabular}{ l >{\setlength{\rightskip}{0pt plus 1fil}}p{30em} } \toprule \multicolumn{1}{c}{\textbf{EAPI}} & \multicolumn{1}{c}{\textbf{Supports \t{default\_} functions in phases}} \\ \midrule \t{0} & None \\ \t{1} & None \\ \t{2} & \t{pkg\_nofetch}, \t{src\_unpack}, \t{src\_prepare}, \t{src\_configure}, \t{src\_compile}, \t{src\_test} \\ \t{3} & \t{pkg\_nofetch}, \t{src\_unpack}, \t{src\_prepare}, \t{src\_configure}, \t{src\_compile}, \t{src\_test} \\ \t{4} & \t{pkg\_nofetch}, \t{src\_unpack}, \t{src\_prepare}, \t{src\_configure}, \t{src\_compile}, \t{src\_install}, \t{src\_test} \\ \t{5} & \t{pkg\_nofetch}, \t{src\_unpack}, \t{src\_prepare}, \t{src\_configure}, \t{src\_compile}, \t{src\_install}, \t{src\_test} \\ \bottomrule \end{tabular} \end{centertable} \section{Call Order} The call order for installing a package is: \begin{compactitem} \item \t{pkg\_pretend} (only for EAPIs listed in table~\ref{tab:pkg-pretend-table}), which is called outside of the normal call order process. \item \t{pkg\_setup} \item \t{src\_unpack} \item \t{src\_prepare} (only for EAPIs listed in table~\ref{tab:src-prepare-table}) \item \t{src\_configure} (only for EAPIs listed in table~\ref{tab:src-configure-table}) \item \t{src\_compile} \item \t{src\_test} (except if \t{RESTRICT=test} or disabled by user) \item \t{src\_install} \item \t{pkg\_preinst} \item \t{pkg\_postinst} \end{compactitem} The call order for uninstalling a package is: \begin{compactitem} \item \t{pkg\_prerm} \item \t{pkg\_postrm} \end{compactitem} The call order for upgrading, downgrading or reinstalling a package is: \begin{compactitem} \item \t{pkg\_pretend} (only for EAPIs listed in table~\ref{tab:pkg-pretend-table}), which is called outside of the normal call order process. \item \t{pkg\_setup} \item \t{src\_unpack} \item \t{src\_prepare} (only for EAPIs listed in table~\ref{tab:src-prepare-table}) \item \t{src\_configure} (only for EAPIs listed in table~\ref{tab:src-configure-table}) \item \t{src\_compile} \item \t{src\_test} (except if \t{RESTRICT=test}) \item \t{src\_install} \item \t{pkg\_preinst} \item \t{pkg\_prerm} for the package being replaced \item \t{pkg\_postrm} for the package being replaced \item \t{pkg\_postinst} \end{compactitem} Note: When up- or downgrading a package in EAPI 0 or 1, the last four phase functions can alternatively be called in the order \t{pkg\_preinst}, \t{pkg\_postinst}, \t{pkg\_prerm}, \t{pkg\_postrm}. This behaviour is deprecated. The \t{pkg\_config}, \t{pkg\_info} and \t{pkg\_nofetch} functions are not called in a normal sequence. The \t{pkg\_pretend} function is called some unspecified time before a (possibly hypothetical) normal sequence. For installing binary packages, the \t{src} phases are not called. When building binary packages that are not to be installed locally, the \t{pkg\_preinst} and \t{pkg\_postinst} functions are not called. % vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en : %%% Local Variables: %%% mode: latex %%% TeX-master: "pms" %%% LaTeX-indent-level: 4 %%% LaTeX-item-indent: 0 %%% TeX-brace-indent-level: 4 %%% fill-column: 100 %%% End: