Gentoo Portage Slot Conflict

Posted By admin On 24/07/22

Section: Portage (5)

If the conflict solely involves built slot-operator (foo/bar:X/Y=) dependencies (the -verbose-conflicts option can help you determine this), then you should temporarily add the emerge -pretend and -ignore-built-slot-operator-deps=y options to your emerge command, as discussed in the answer to the previous question. Gentoo Portage Slot Conflict their gaming policies, Gentoo Portage Slot Conflict therefore you will never find that as a possibility within your Gentoo Portage Slot Conflict online casino career. However, there is a possibility to try out the no deposit bonuses that come with no turnover requirements.

Updated: Jul 2019
Index

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 fromits original sources. In addition to all of this, the ebuild script can alsocontain pre/post install/remove commands, as required. All ebuild scripts arewritten in bash.

Dependencies

A depend atom is simply a dependency that is used by portage whencalculating relationships between packages. Please note that if the atom hasnot already been emerged, then the latest version available is matched.

Atom Bases

The base atom is just a full category/packagename. Another name for a fullcategory/packagename is a 'catpkg'. You will find this shorthand-nameused frequently in Gentoo. Here are some base atoms, a.k.a 'catpkgs':

Atom Versions

It is nice to be more specific and say that only certain versions of atoms areacceptable. Note that versions must be combined with a prefix (see below).Hence you may add a version number as a postfix to the base.

Examples:

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.2aor 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 the3rd pre-release of a package, you would use something like 1.2_pre3. Thesuffixes here can be arbitrarily chained without limitation.

Atom Prefix Operators [> >= = <= <]

Sometimes you want to be able to depend on general versions rather thanspecifying exact versions all the time. Hence we provide standard booleanoperators:

Examples:

Extended Atom Prefixes [!~] and Postfixes [*]

Now to get even fancier, we provide the ability to define blocking packages andversion range matching. Also note that these extended prefixes/postfixes maybe combined in any way with the atom classes defined above.

means match any revision of the base version specified. So in theexample below, we would match versions '1.0.2a', '1.0.2a-r1', '1.0.2a-r2',etc...

Example:

means block packages from being installed at the same time.

Example:

means block packages from being installed at the same timeand explicitly disallow them from being temporarily installedsimultaneously during a series of upgrades. This syntax is supportedbeginning with EAPI 2.

Example:

means match any version of the package so long as the specified baseis 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... The version partthat 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*' isallowed and '2.*' is not.

Examples:

Atom Slots

Beginning with EAPI 1, any atom can be constrained to match a specificSLOT. This is accomplished by appending a colon followed by aSLOT:

Examples:

Sub Slots

Beginning with EAPI 5, a slot dependency may contain anoptional sub-slot part that follows the regular slot and isdelimited by a / character.

Examples:

Atom Slot Operators

Beginning with EAPI 5, slot operator dependency consistsof a colon followed by one of the following operators:

Indicates that any slot value is acceptable. In addition,for runtime dependencies, indicates that the package will notbreak if the matched package is uninstalled and replaced bya different matching package in a different slot.

Examples:

Indicates that any slot value is acceptable. In addition,for runtime dependencies, indicates that the package willbreak unless a matching package with slot and sub-slot equalto the slot and sub-slot of the best installed version at thetime the package was installed is available.

Examples:

slot=

Indicates that only a specific slot value is acceptable, andotherwise behaves identically to the plain equals slot operator.

Examples:

To implement the equals slot operator, the package managerwill need to store the slot/sub-slot pair of the best installedversion of the matching package. This syntax is only for packagemanager use and must not be used by ebuilds. The package managermay do this by inserting the appropriate slot/sub-slot pairbetween the colon and equals sign when saving the package'sdependencies. The sub-slot part must not be omitted here(when the SLOT variable omits the sub-slot part, the packageis considered to have an implicit sub-slot which is equal tothe regular slot).

Examples:

Atom USE

Beginning with EAPI 2, any atom can be constrained to match specificUSE flag settings. When used together with SLOT dependencies,USE dependencies appear on the right hand side of SLOTdependencies.

Unconditional USE Dependencies

Example	Meaning
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 Form	Equivalent Expanded Form
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 defaultassumptions about values for flags that may or may not be missing fromthe IUSE of the matched package. Such defaults are specified byimmediately 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:

Examples:

Dynamic Dependencies

Sometimes programs may depend on different things depending on the USEvariable. Portage offers a few options to handle this. Note that whenusing the following syntaxes, each case is considered as 1 Atom in thescope it appears. That means that each Atom both conditionally includemultiple Atoms and be nested to an infinite depth.

usevar? ( Atom )

To include the jpeg library when the user has jpeg in USE, simply use thefollowing syntax:

jpeg? ( media-libs/jpeg )

!usevar? ( Atom )

If you want to include a package only if the user does not have a certainoption 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 optionalsupport 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 usetwo statements, one normal and one inverted. If a package usesGTK2 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 notappropriate, this syntax can easily be used.

Example:

Here we see that unreal-tournament has a normal version and it has a gotyversion. Since they provide the same base set of files, another package canuse 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 videointerfaces, but it can only ever have just one.

Example:

Here only one of the packages will be chosen, and the order of preference isdetermined by the order in which they appear. So sdl has the best chance ofbeing chosen, followed by svga, then opengl, then ggi, with a default of X ifthe user does not specify any of the previous choices.

Note that if any of the packages listed are already merged, the package managerwill use that to consider the dependency satisfied.

Variable Usage Notes

*: Variables defined in make.conf(5) are available for use inebuilds (except Portage-specific variables, which might be not supported byother package managers).
*: When assigning values to variables in ebuilds, you cannot have aspace between the variable name and the equal sign.
*: Variable values should only contain characters that are members of theascii(7) character set. This requirement is mandated by GLEP 31.

Variables Used In Ebuilds

ARCH

This variable contains the official Gentoo-specific acronym for the currentarchitecture of the running system. For an authoritative list pleasereview /var/db/repos/gentoo/profiles/arch.list.

This variable contains the package name without the ebuild revision.This variable must NEVER be modified.

Example:

Contains the name of the script without the version number.

Example:

Contains the version number without the revision.

Example:

Contains the revision number or 'r0' if no revision number exists.

Example:

PVR

Contains the version number with the revision (if non-zero).

Example:

Contains the full package name PN-PVR

Examples:

CATEGORY

Contains the package category name.

Example:

Contains all source files required for the package. This variable mustnot 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 = ${PORTAGE_TMPDIR}/${CATEGORY}/${PF}/files

Contains the path to the directory in which package-specific auxiliaryfiles are located. Do not modify this variable.

EBUILD_PHASE

Contains the abreviated name of the phase function that iscurrently executing, such as 'setup', 'unpack', 'compile', or'preinst'.

EBUILD_PHASE_FUNC

Beginning with EAPI 5, contains the full name of the phasefunction that is currently executing, such as 'pkg_setup','src_unpack', 'src_compile', or 'pkg_preinst'.

EPREFIX

Beginning with EAPI 3, contains the offsetthat this Portage was configured for duringinstallation. The offset is sometimes necessary in an ebuild or eclass,and is available in such cases as ${EPREFIX}. EPREFIX does not containa trailing slash, therefore an absent offset is represented by the emptystring. Do not modify this variable.

S = ${WORKDIR}/${P}

Contains the path to the temporary build directory. This variableis used by the functions src_compile and src_install. Bothare executed with S as the current directory. This variable maybe 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 forwhatever you like.

D = ${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/image/

Contains the path to the temporary install directory. Every writeoperation that does not involve the helper tools and functions (found below)should be prefixed with ${D}.Beginning with EAPI 3, the offset prefix often needsto be taken into account here, for which the variable${ED} is provided (see below).Note that with EAPI 7, any trailing slashcontained in this path will be automatically removed for ease of concatenatingpaths within ebuilds.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 donot support ED, helpers use D wherethey would otherwise use ED. Note that with EAPI 7, any trailing slashcontained in this path will be automatically removed for ease of concatenatingpaths within ebuilds.Do not modify this variable.

MERGE_TYPE

Beginning with EAPI 4, the MERGE_TYPE variable can be used toquery the current merge type. This variable will contain one of thefollowing possible values:

Value	Meaning
buildonly	source-build which is not scheduled for merge
source	source-build which is scheduled for merge

PROVIDES_EXCLUDE = [space delimited list of fnmatch patterns]

Sonames and file paths matched by these fnmatch patterns will beexcluded during genertion of PROVIDES metadata (seeportage(5)). Patterns are delimited by whitespace, and it ispossible to create patterns containing quoted whitespace.

PORTAGE_LOG_FILE

Contains the path of the build log. If PORTAGE_LOGDIR variable is unset thenPORTAGE_LOG_FILE='${T}/build.log'.

PORTAGE_SOCKS5_PROXY

Contains the UNIX socket path to SOCKSv5 proxy providing host networkaccess. Available only when running inside network-sandbox and a proxyis available (see network-sandbox in make.conf(5)).

REPLACED_BY_VERSION

Beginning with EAPI 4, the REPLACED_BY_VERSION variable can beused in pkg_prerm and pkg_postrm to query the package version thatis replacing the current package. If there is no replacement package,the variable will be empty, otherwise it will contain a single versionnumber.

REPLACING_VERSIONS

Beginning with EAPI 4, the REPLACING_VERSIONS variable can beused in pkg_pretend, pkg_setup, pkg_preinst and pkg_postinst to querythe package version(s) that the current package is replacing. If thereare no packages to replace, the variable will be empty, otherwise itwill contain a space-separated list of version numbers correspondingto the package version(s) being replaced. Typically, this variable willnot contain more than one version, but according to PMS it can containmore.

REQUIRES_EXCLUDE = [space delimited list of fnmatch patterns]

Sonames and file paths matched by these fnmatch patterns will beexcluded during generation of REQUIRES metadata (seeportage(5)). Patterns are delimited by whitespace, and it ispossible to create patterns containing quoted whitespace.

ROOT = /

Please note an important recent change regarding the ROOT variable -- in EAPI 7 ebuilds,this variable will default to ' rather than the traditional '/' within ebuildswhen pointing to the root filesystem, and when set to a non-root paththis variable will never contain a trailing slash. This has the addedconvenience of eliminating the need tospecify '${ROOT%/}' when concatenating paths, making the use of ROOTmore elegant. This applies to the variables EROOT, D and ED as well. Pleasemake note that this willmean that ebuilds must use different logic in conditionals to determine ifthey are installing to the root filesystem -- use [[ '$ROOT' ' ]] instead of[[ '$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 inthe tree prefixed by ${ROOT}. Often the offset prefix needs to be takeninto account here, for which the variable ${EROOT} is provided (seebelow). Do not modify this variable.

EROOT = ${ROOT%/}${EPREFIX}/

Beginning with EAPI 3, contains'${ROOT%/}${EPREFIX}/' for conveniencepurposes. Do not modify this variable. Also see the important note regardingROOT with EAPI 7, above. As with ROOT, EROOT will be defined as 'when set to the root filesystem and never have a trailing slash within anebuild.

BROOT = ${EPREFIX}

Beginning with EAPI 7, the absolute path to the root directorycontaining build dependencies satisfied by BDEPEND, typicallyexecutable build tools. This includes any applicable offset prefix. Donot 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 notdefined then it defaults to '0'. If portage does not recognize theEAPI value then it will mask the package and refuse to perform anyoperations with it since this means that a newer version of portageneeds to be installed first. For maximum backward compatiblity, apackage should conform to the lowest possible EAPI. Note that anyonewho uses the ebuild(1) and repoman(1) commands with thispackage will be required to have a version of portage that recognizesthe EAPI to which this package conforms.

SRC_URI = https://example.com/path/${P}.tar.gz

Contains a list of URIs for the required source files. It can containmultiple URIs for a single source file. The list is processed in orderif the file was not found on any of the GENTOO_MIRRORS.Beginning with EAPI 2, the output file name of a given URI may becustomized with a '->' operator on the right hand side, followed by thedesired output file name. All tokens, including the operator and outputfile name, should be separated by whitespace.

HOMEPAGE = https://example.com/

Should contain a list of URIs for the sources main sites and other furtherpackage dependent information.

KEYWORDS = [-~][x86,ppc,sparc,mips,alpha,arm,hppa,...]

KEYWORDS works in conjunction with ACCEPT_KEYWORDS (see make.conf(5))to implement a system of creating sets of different types of packageswhich can then be masked or unmasked en masse. In the Gentoo Linuxproject, they are used by the Gentoo arch teams to define what ebuildsare included in a particular CPU architecture's set of stable and unstableunmasked packages.

Here's how they work. For purposes of explanation, let's assume you havea stable x86-64bit system, typically referred to as 'amd64'.ARCH would be defined as 'amd64'. If you were using the stable build ofGentoo Linux, then ACCEPT_KEYWORDS would be set to 'amd64' via profiles.Any ebuild that then has'amd64' in KEYWORDS will be unmasked by default.

On an 'unstable'amd64 system, ACCEPT_KEYWORDS will be set to 'amd64 ~amd64', with thetilde denoting 'unstable.' Then, if an ebuild has either'amd64' or '~amd64' in KEYWORDS, it will be keyword unmasked by default onthat system. Similarly, if an ebuild is known to not be compatiblewith a particular architecture, the '-' prefix ( i.e. '-amd64') settingcan be specified to mask it only on that arch.If you are developing ebuilds for Gentoo Linux, there are certainpolicies regarding KEYWORDS that you are expected to follow in orderto align with Gentoo's arch team workflow. The most importantpolicies are listed below:

If you do not know if an ebuild runs under a particular arch, then do notspecify it in KEYWORDS.It will then be masked by default on that architecture.

If the ebuild is known not to work on an arch, disable that arch in KEYWORDS.This would be done by specifying '-ppc', for example. This will ensure thatit is explicitly keyword-masked for that architecture.

When submitting an ebuild to Gentoo Linux, it is the project policy to onlyhave '~arch' set in KEYWORDSfor the architecture for which it has been successfully tested, and no more.As the ebuild receives more testing, Gentoo arch teams will gradually expandthe KEYWORDS settings to 'bump' the package to unstable, and possibly stable.

It is possible to customize the behavior of ACCEPT_KEYWORDS and KEYWORDS ona per-package basis using package.accept_keywords and package.keywords filesin profiles. See portage(5) for more information on using these files.

Note that while other Gentoo-based projectshave KEYWORDS and ACCEPT_KEYWORDS, they likely will not have exactlythe same policies regarding their use. Therefore, it is necessary that youresearch their specific policies and how they differ from Gentoo.

SLOT

This sets the SLOT for packages that may need to have multiple versionsco-exist. By default you should set SLOT='0'. If you are unsure, thendo not fiddle with this until you seek some guidance from some guru. Thisvalue should NEVER be left undefined.

Beginning with EAPI 5, the SLOT variable may containan optional sub-slot part that follows the regular slot andis delimited by a / character. The sub-slot must be a validslot name. The sub-slot is used to represent cases in whichan upgrade to a new version of a package with a differentsub-slot may require dependent packages to be rebuilt. Whenthe sub-slot part is omitted from the SLOT definition, thepackage is considered to have an implicit sub-slot which isequal to the regular slot. Refer to the Atom SlotOperators section for more information about sub-slotusage.

LICENSE

This should be a space delimited list of licenses that the package fallsunder. This _must_ be set to a matching license in/var/db/repos/gentoo/licenses/. If the license does not exist in the repositoryyet, you must add it first.

IUSE

This should be a list of any and all USE flags that are leveraged withinyour build script. The only USE flags that should not be listed here arearch related flags (see KEYWORDS). Beginning with EAPI 1, itis possible to prefix flags with + or - in order to create default settingsthat respectively enable or disable the corresponding USE flags. Fordetails about USE flag stacking order, refer to the USE_ORDERvariable in make.conf(5). Given the default USE_ORDER setting,negative IUSE default settings are effective only for negation ofrepo-level USE settings, since profile and user configuration settingsoverride them.

DEPEND

This should contain a list of all packages that are required for the programto compile (aka buildtime dependencies). These are usually libraries andheaders.

Starting from EAPI 7, tools should go into the BDEPENDvariable instead, as DEPEND will only be installed into thesystem being built and hence cannot be executed when cross-compiling.

You may use the syntax described above in the Dependencies section.

RDEPEND

This should contain a list of all packages that are required for thisprogram to run (aka runtime dependencies). These are usually libraries.

In EAPI 3 or earlier, if this is not set, then it defaults to the valueof DEPEND. In EAPI 4 or later, RDEPEND will never beimplicitly set.

You may use the syntax described above in the Dependencies section.

BDEPEND

This should contain a list of all packages that are required to beexecutable during compilation of this program (aka native builddependencies). These are usually tools, like interpreters or(cross-)compilers. They will be installed into the system performingthe build.

This variable was formally introduced in EAPI 7 but waspreviously known as HDEPEND in the experimentalEAPI 5-hdepend.

You may use the syntax described above in the Dependencies section.

PDEPEND

This should contain a list of all packages that should be merged after thisone (aka post merge dependencies), but which may be installed by thepackage manager at any time, if that is not possible.

***WARNING***
Use this only as last resort to break cyclic dependencies!

You may use the syntax described above in the Dependencies section.

REQUIRED_USE

Beginning with EAPI 4, the REQUIRED_USE variable can beused to specify combinations of USE flags that are allowedor not allowed. Elements can be nested when necessary.

Behavior	Expression
If flag1 enabled then flag2 enabled	flag1? ( 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 )
May enable at most one (EAPI 5 or later)	?? ( 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 packagesfor which binary checks make no sense (linux-headers and kernel-sources, forexample, can safely be skipped since they have no binaries). If the binarychecks 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 withbinaries that are not compatible with debugedit.
mirror: files in SRC_URI will not be downloaded from the GENTOO_MIRRORS.
network-sandbox: Disables the network namespace for specific packages.Should not be used in the main Gentoo tree.
preserve-libs: Disables preserve-libs for specific packages. Note than when a package ismerged, RESTRICT=preserve-libs applies if either the new instance or theold instance sets RESTRICT=preserve-libs.
primaryuri: fetch from URIs in SRC_URI before GENTOO_MIRRORS.
splitdebug: Disables splitdebug for specific packages. This is for packages withbinaries that trigger problems with splitdebug, such as file-collisionsbetween symlinks in /usr/lib/debug/.build-id (triggered by bundled libraries).
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,live]

A space delimited list of properties, with conditional syntax support.

interactive: One or more ebuild phases will produce a prompt that requires user interaction.
live: The package uses live source code that may vary each time that the packageis installed.

DOCS

Beginning with EAPI 4, an array or space-delimited list of documentationfiles for the default src_install function to install using dodoc. Ifundefined, a reasonable default list is used. See the documentation forsrc_install below.

QA Control Variables:

Usage Notes

Several QA variables are provided which allow an ebuild to manipulate someof the QA checks performed by portage. Use of these variables in ebuildsshould be kept to an absolute minimum otherwise they defeat the purposeof 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-sourcebinary 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 imagedirectory, of files that are pre-built binaries. Pathslisted here will be appended to each of the QA_* variableslisted below. The paths may contain fnmatch-like patternswhich will be internally translated to regular expressions forthe QA_* variables that support regular expressions insteadof fnmatch patterns. The translation mechanism simply replaces'*' with '.*'.

QA_TEXTRELS

This variable can be set to a list of file paths, relative to the imagedirectory, 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 thatcannot be altered.

QA_EXECSTACK

This should contain a list of file paths, relative to the image directory, ofobjects 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 executablestack (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, offiles 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, offiles that do not contain .GCC.command.line sections or contain .hash sections.The paths may contain regular expressions with escape-quoted specialcharacters.

This variable is intended to be used on files of binary packages which ignoreCFLAGS, CXXFLAGS, FFLAGS, FCFLAGS, and LDFLAGS variables.

QA_MULTILIB_PATHS

This should contain a list of file paths, relative to the image directory, offiles that should be ignored for the multilib-strict checks.The paths may contain regular expressions with escape-quoted specialcharacters.

QA_PRESTRIPPED

This should contain a list of file paths, relative to the image directory, offiles that contain pre-stripped binaries. The paths may contain regularexpressions with escape-quoted special characters.

QA_SONAME

This should contain a list of file paths, relative to the image directory, ofshared libraries that lack SONAMEs. The paths may contain regular expressionswith escape-quoted special characters.

QA_SONAME_NO_SYMLINK

This should contain a list of file paths, relative to the image directory, ofshared libraries that have SONAMEs but should not have a corresponding SONAMEsymlink in the same directory. The paths may contain regular expressionswith escape-quoted special characters.

QA_AM_MAINTAINER_MODE

This should contain a list of lines containing automake missing --runcommands. The lines may contain regular expressions with escape-quotedspecial characters.

QA_CONFIGURE_OPTIONS

This should contain a list of configure options which trigger warnings aboutunrecognized options. The options may contain regular expressions withescape-quoted special characters.

QA_DT_NEEDED

This should contain a list of file paths, relative to the image directory, ofshared libraries that lack NEEDED entries. The paths may contain regularexpressions with escape-quoted special characters.

QA_DESKTOP_FILE

This should contain a list of file paths, relative to the image directory, ofdesktop files which should not be validated. The paths may contain regularexpressions with escape-quoted special characters.

PORTAGE DECLARATIONS

.eclass extension. Also note that the inherit statement must comebefore other variable declarations unless these variables are used in globalscope of eclasses.

PHASE FUNCTIONS

pkg_pretend

Beginning with EAPI 4, this function can be defined in order tocheck that miscellaneous requirements are met. It is called as earlyas possible, before any attempt is made to satisfy dependencies. If thefunction detects a problem then it should call eerror and die. Theenvironment (variables, functions, temporary directories, etc..) thatis used to execute pkg_pretend is not saved and therefore is notavailable in phases that execute afterwards.

pkg_nofetch

This function will be executed when the files in SRC_URIcannot be fetched for any reason. If you turn on fetch inRESTRICT, this is useful for displaying information to theuser on *how* to obtain said files. Allyou have to do is output a message and let the function return. Do notend the function with a call to die.

pkg_setup

This function can be used if the package needs specific setup actions orchecks to be preformed before anything else.
Initial working directory: $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}. Anypatches and other pre configure/compile modifications should be done here.
Initial working directory: $WORKDIR

Gentoo Portage Slot Conflict Guide

src_prepare

All preparation of source code, such as application of patches, should be donehere. This function is supported beginning with EAPI 2.
Initial working directory: $S

src_configure

All necessary steps for configuration should be done here. This function issupported beginning with EAPI 2.
Initial working directory: $S

src_compile

With less than EAPI 2, all necessary steps for both configuration andcompilation should be done here. Beginning with EAPI 2, only compilationsteps should be done here.
Initial working directory: $S

src_test

Run all package specific test cases. The default is to run'emake check' followed 'emake test'. Prior to EAPI 5,the default src_test implementation will automatically pass the-j1 option as the last argument to emake, and beginning withEAPI 5 it will allow the tests to run in parallel.
Initial working directory: $S

src_install

Should contain everything required to install the package in the temporaryinstall directory.
Initial working directory: $S

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

pkg_preinst pkg_postinst

All modifications required on the live-filesystem before and after thepackage is merged should be placed here. Also commentary for the usershould be listed here as it will be displayed last.
Initial working directory: $PWD

pkg_prerm pkg_postrm

Like the pkg_*inst functions but for unmerge.
Initial working directory: $PWD

pkg_config

This function should contain optional basic configuration steps.
Initial working directory: $PWD

HELPER FUNCTIONS

Phases:

default

Calls the default phase function implementation for the currently executingphase. This function is supported beginning with EAPI 2.

default_*

Beginning with EAPI 2, the default pkg_nofetch and src_* phasefunctions are accessible via a function having a name that begins withdefault_ and ends with the respective phase function name. For example,a call to a function with the name default_src_compile is equivalent toa call to the default src_compile implementation.

Default Phase Functions

default_src_unpack

default_src_prepare

default_src_configure

default_src_compile

default_src_test

General:

assert[reason]

Checks the value of the shell's PIPESTATUS array variable, and if anycomponent is non-zero (indicating failure), calls die with reasonas a failure message.

die[reason]

Causes the current emerge process to be aborted. The final display willinclude reason.

Beginning with EAPI 4, all helpers automatically call diewhenever some sort of error occurs. Helper calls may be prefixed withthe 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 silentlyreturn 0 (aka shell true). If USE item is not in the USEvariable, the function will silently return 1 (aka shell false). usevis a verbose version of use.

Example:

usev<USE item>

Like use, but also echoes USE item when use returns true.

usex<USE flag>[true output][false output][true suffix][false suffix]

If USE flag is set, echo [true output][true suffix] (defaults to'yes'), otherwise echo [false output][false suffix] (defaults to'no'). The usex helper is available beginning with EAPI 5.

use_with<USE item>[configure name][configure opt]

Useful for creating custom options to pass to a configure script. If USEitem is in the USE variable and a configure opt is specified,then the string --with-[configure name]=[configure opt] will beechoed. If configure opt is not specified, then just--with-[configure name] will be echoed. If USE item is not inthe USE variable, then the string --without-[configure name]will be echoed. If configure name is not specified, then USE itemwill be used in its place. Beginning with EAPI 4, an empty configureopt argument is recognized. In EAPI 3 and earlier, an emptyconfigure opt argument is treated as if it weren't provided.

Examples:

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- insteadof --without-. Beginning with EAPI 4, an empty configureopt argument is recognized. In EAPI 3 and earlier, an emptyconfigure opt argument is treated as if it weren't provided.

has<item><item list>

If item is in item list, then has returns0. Otherwise, 1 is returned. There is another version, hasv, thatwill conditionally echo item.
The item list is delimited by the IFS variable. This variablehas a default value of ' ', or a space. It is a bash(1) setting.

hasv<item><item list>

Like has, but also echoes item when has returns true.

has_version[-b][-d][-r][--host-root]<category/package-version>

Check to see if category/package-version is installed. Theparameter accepts all values that are acceptable in the DEPENDvariable. The function returns 0 if category/package-versionis installed, 1 otherwise. The package is searched for in ROOTby default.

In EAPI 5 and EAPI 6, the package is searched for in thebuild host if the --host-root option is given.

In EAPI 7 and later, the confusing --host-root optionhas been replaced with -b, which corresponds to a dependencysatisfied by BDEPEND in the build host. Similarly, the-d option corresponds to DEPEND in SYSROOT and the-r option corresponds to RDEPEND in ROOT.

best_version[-b][-d][-r][--host-root]<package name>

This function will look up package name in the database ofcurrently installed packages and echo the 'best version' of thepackage that is found or nothing if no version is installed. Thepackage is searched for in ROOT by default. It accepts the sameoptions as has_version.

Example:

Output:

eloginformative message: If you need to display a message that you wish the user to read and takenotice of, then use elog. It works just like echo(1), butadds a little more to the output so as to catch the user's eye. The messagewill also be logged by portage for later review.
ewarnwarning message: Same as einfo, but should be used when showing a warning to the user.
eqawarnQA warning message: Same as einfo, but should be used when showing a QA warning to the user.
eerrorerror message: Same as einfo, but should be used when showing an error to the user.
ebeginhelpful message: Like einfo, we output a helpful message and then hint that thefollowing operation may take some time to complete. Once the task isfinished, you need to call eend.
eend<status>[error message]: Followup the ebegin message with an appropriate 'OK' or '!!' (forerrors) marker. If status is non-zero, then the additional errormessage is displayed.

Unpack:

docompress[-x] <path> [list of more paths]
doseds:orig:change:g <filename>
dodir<path> [more paths]: Creates directories inside of ${ED}.
'dodir /usr/lib/apache'creates ${ED}/usr/lib/apache. Note that the do* functions will rundodir for you. If this directory will be empty when it is merged,then please use keepdir instead.
diropts[options for install(1)]: Can be used to define options for the install function used indodir. 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> [more paths]: Similar to dodir, but used to create directories that would otherwisebe empty. The treatment of completely-empty directories is undefined byPMS, and using keepdir ensures that they are tracked.
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 thecorrect location for Gentoo init.d scripts (/etc/init.d/). Creates allnecessary dirs.
doconfd<conf.d file> [list of more conf.d file]: Install Gentoo conf.d files. They will be installed into thecorrect location for Gentoo conf.d files (/etc/conf.d/). Creates allnecessary dirs.
doenvd<env.d entry> [list of more env.d entries]: Install Gentoo env.d entries. They will be installed into thecorrect location for Gentoo env.d entries (/etc/env.d/). Creates allnecessary 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 inthe 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 themanual file ending. The files are compressed if they are not already. Youcan specify locale-specific manpages with the -i18n option. Then theman-page will be installed into /usr/share/man/<locale>/man[0-9n].Beginning with EAPI 2, a locale-specific manpage which contains a localein 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 optionhas no effect. For example, with EAPI 2, a manpage namedfoo.<locale>.1 will be installed as/usr/share/man/<locale>/man1/foo.1. Beginning with EAPI 4,the -i18n option takes precedence over the locale suffix of thefile name.
dohard<filename> <linkname>: Beginning with EAPI 4, the dohard helper no longer exists. Ebuildsshould call ln(1) directly.
dosym<filename> <linkname>: Performs the ln command to create a symlink.
doheader[-r] <file> [list of more files]: Installs the given header files into /usr/include/, by defaultwith file mode 0644 (this can be overridden with theinsopts function). Setting -r sets recursive. Thedoheader helper is available beginning with EAPI 5.
dohtml [-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}/html provided the file ends in .htm, .html, .css, .js, Setting -a limits what types of files will be included,-A appends to the default list, setting -x sets which dirs toexclude (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 automaticallygzipped. 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[-h -H -L -P -R] [user][:group] <file> [files]
fperms[-R] <permissions> <file> [files]: Performs chown (fowners) or chmod (fperms), applyingpermissions 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 indoins. The default is -m0644.
doins[-r] <file> [list of more files]: Installs files into the path controlled by insinto. This functionuses install(1). Creates all necessary dirs.Setting -r sets recursive. Beginning with EAPI 4, bothdoins and newins preserve symlinks. In EAPI 3 andearlier, 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 functionuses install(1). Creates all necessary dirs.
docinto[path]: Sets the subdir used by dodoc and dohtmlwhen 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 thenew -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>
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 onefile and the file is installed as [new filename].Beginning with EAPI 5, standard input is read when thefirst parameter is - (a hyphen).

cremocnagesaco.netlify.com

Gentoo Portage Slot Conflict

NAME

DESCRIPTION

Dependencies

Variable Usage Notes

Variables Used In Ebuilds

QA Control Variables:

PORTAGE DECLARATIONS

PHASE FUNCTIONS

Gentoo Portage Slot Conflict Guide

HELPER FUNCTIONS

Phases:

General:

Output:

Unpack:

Gentoo Portage Slot Conflict Buster

Gentoo Portage Slot Conflict Bracket

EXAMPLES

FILES

SEE ALSO

REPORTING BUGS

AUTHORS

Index