Portage Variables - Revision history

Drobbins: updating to reflect recent Portage/Funtoo changes

2013-04-25T21:05:22Z

updating to reflect recent Portage/Funtoo changes

64.238.164.197: /* KEYWORDS */

2013-04-25T16:11:52Z

‎KEYWORDS

Drobbins: /* Profile Variables */

2013-04-05T01:48:09Z

‎Profile Variables

Drobbins: /* Metadata Variables */

2013-04-05T01:41:42Z

‎Metadata Variables

404 Error: /* KEYWORDS */

2011-04-18T20:28:21Z

‎KEYWORDS

404 Error: /* Introduction */

2011-03-09T12:42:30Z

‎Introduction

404 Error: /* Introduction */

2011-03-09T12:41:18Z

‎Introduction

404 Error: /* Introduction */

2011-03-09T12:37:57Z

‎Introduction

404 Error: /* KEYWORDS */

2011-03-09T12:09:46Z

‎KEYWORDS

404 Error: /* KEYWORDS */

2011-03-09T12:09:22Z

‎KEYWORDS

@@ Line 169: / Line 169: @@
 * The package has been pushed in the portage tree but remains to go in a intensive test cycle before being tagged as current then stable).
-In a user's <tt>/etc/make.conf</tt>, <tt>ACCEPT_KEYWORDS</tt> variable is defined which specifies what specific keywords should be unmasked for this system by default. This value defaults to the stable tree of the current system architecture. On Funtoo Linux systems, ACCEPT_KEYWORDS is set to one of six values:
+In a user's arch profile (see <tt>eselect profile list</tt>.) <tt>ACCEPT_KEYWORDS</tt> variable is defined which specifies what specific keywords should be unmasked for this system by default. On Funtoo Linux systems, ACCEPT_KEYWORDS is set to one of six values:
 ;<tt>amd64</tt>
@@ Line 207: / Line 207: @@
 {{ fancyimportant|'''x86''', '''amd64''' or '''sparc''' setting in the ebuild's KEYWORDS will unmask the ebuild for both current and stable tree systems -- that is, any ebuild made available to stable is also made available to current. }}
-Additional wildcard keywords are supported:
+Additional wildcard keywords are supported in ebuilds:
 ;<tt>*</tt>
@@ Line 216: / Line 216: @@
 ===== Gentoo Linux KEYWORDS Policies =====
-Due to the exclusive use of KEYWORDS by the Gentoo Linux architecture teams, a number of unfortunate policy-related checks have been integrated into the Portage source code. One is banning the use of <tt>KEYWORDS="*"</tt> to enable KEYWORDS for all available architectures, since it is Gentoo Linux policy for each architecture team to independently verify an ebuild one architecture at a time - this rule currently applies to all ebuilds, including architecture-independent ebuilds. These policy checks will result in warnings being displayed by Portage when using certain combinations of wildcard keywords. This also means that virtually all ebuilds originating from Gentoo Linux will specify an exhaustive, explicit list of all architecture trees for which this package has been unmasked, which will look something like this:
+Due to the exclusive use of KEYWORDS by the Gentoo Linux architecture teams, a number of unfortunate policy-related checks have been integrated into the Portage source code. One is banning the use of <tt>KEYWORDS="*"</tt> to enable KEYWORDS for all available architectures, since it is Gentoo Linux policy for each architecture team to independently verify an ebuild one architecture at a time - this rule currently applies to all ebuilds, including architecture-independent ebuilds. This means that virtually all ebuilds originating from Gentoo Linux will specify an exhaustive, explicit list of all architecture trees for which this package has been unmasked, which will look something like this:
 <source lang="bash">
 KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd"
 </source>
 [[Category:Internals]]
 [[Category:Portage]]

@@ Line 189: / Line 189: @@
 :ebuild unmasked in 64-bit PC-compatible stable '''and current''' trees
 ;<tt>~amd64</tt>
-:ebuild unmasked in 64-bit PC-compatible stable tree only
+:ebuild unmasked in 64-bit PC-compatible current tree only
 ;<tt>-amd64</tt>
 :ebuild masked for all 64-bit PC-compatible trees
@@ Line 195: / Line 195: @@
 :ebuild unmasked in 32-bit PC-compatible stable '''and current''' trees
 ;<tt>~x86</tt>
-:ebuild unmasked in 32-bit PC-compatible stable tree only
+:ebuild unmasked in 32-bit PC-compatible current tree only
 ;<tt>-x86</tt>
 :ebuild masked for all 32-bit PC-compatible trees
 ;<tt>sparc</tt>
 :ebuild unmasked in SPARC stable '''and current''' trees
 ;<tt>-sparc</tt>
 :ebuild masked for all sparc trees

@@ Line 6: / Line 6: @@
 === Profile Variables ===
 ; ARCH
@@ Line 69: / Line 71: @@
 # grep -r ARCH= * | cut -f2 -d"=" | sed -e 's/"//g' | sort -u
 </pre>
 === Path Variables ===

← Older revision		Revision as of 01:41, 5 April 2013
Line 127:		Line 127:

	=== Metadata Variables ===		=== Metadata Variables ===
		+
		+	Metadata variables are variables that you set in your ebuild. They are cached by Portage so they can be quickly accessed for dependency resolution and searches -- in <tt>/var/cache/edb/dep</tt>. When an ebuild is updated, Portage automatically updates the cache the next time it notices the ebuild has changed.

	;EAPI		;EAPI

@@ Line 203: / Line 203: @@
 :ebuild masked for all sparc trees
-{{ fancyimportant|'''x86''', '''amd64''' or '''sparc''' setting in the ebuild's KEYWORDS will unmask the ebuild for both current and stable tree systems -- that is, any ebuild made available to stable is also made available to unstable. }}
+{{ fancyimportant|'''x86''', '''amd64''' or '''sparc''' setting in the ebuild's KEYWORDS will unmask the ebuild for both current and stable tree systems -- that is, any ebuild made available to stable is also made available to current. }}
 Additional wildcard keywords are supported:

@@ Line 3: / Line 3: @@
 Ebuild developers as well as users of Portage can control Portage behavior using a number of Portage variables. Also, when an ebuild executes, a number of variables are defined by <tt>ebuild.sh</tt>, the main ebuild script, so they are available for your ebuild. There are also variables that the ebuild writer can define within his or her ebuild to provide information about the ebuild as well as control behavior. Information on [[Ebuild Functions]], which are used to define actions that are performed during various parts of a package's lifecycle, is also available on this wiki.
-{{ fancynote|An '''ebuild''' is a textual meta-description of a software package (stored in a filename suffixed by ''.ebuild'' and generally located in a subdirectory of ''/usr/portage'') that provides the instructions to build and install the later on your system plus a number of additional informations like a brief summary of the package, the required dependencies to build and run the package, where to get the software package source code and so on. Due to the 1:1 matching between an ebuild file and a software package most of Gentoo and Funtoo developers uses the term ''ebuild'' to designate the  meta-description of a package and the software packages it relates in itself. }}
+{{ fancynote|An '''ebuild''' is a textual meta-description of a software package (stored in a filename suffixed by ''.ebuild'' and generally located in a subdirectory of ''/usr/portage'') that provides the instructions to build and install the later on your system plus a number of additional informations like a brief summary of the package, the required dependencies to build and run the package, where to get the software package source code and so on. Due to the 1:1 matching between an ebuild file and a software package most of Gentoo and Funtoo developers uses the term ''ebuild'' to designate the  meta-description of a package and the software package it relates in itself. }}
 === Profile Variables ===

@@ Line 1: / Line 1: @@
 == Introduction ==
-Ebuild developers as well as users of Portage can control Portage behavior using a number of Portage variables. Also, when an ebuild executes, a number of variables are defined by <tt>ebuild.sh</tt>, the main ebuild script, so they are available for your ebuild. There are also variables that the ebuild writer can define within his or her ebuild to provide information about the ebuild as well as control behavior. Information on [Ebuild Functions], which are used to define actions that are performed during various parts of a package's lifecycle, is also available on this wiki. See [Ebuild Functions].
+Ebuild developers as well as users of Portage can control Portage behavior using a number of Portage variables. Also, when an ebuild executes, a number of variables are defined by <tt>ebuild.sh</tt>, the main ebuild script, so they are available for your ebuild. There are also variables that the ebuild writer can define within his or her ebuild to provide information about the ebuild as well as control behavior. Information on [[Ebuild Functions]], which are used to define actions that are performed during various parts of a package's lifecycle, is also available on this wiki.
 {{ fancynote|An '''ebuild''' is a textual meta-description of a software package (stored in a filename suffixed by ''.ebuild'' and generally located in a subdirectory of ''/usr/portage'') that provides the instructions to build and install the later on your system plus a number of additional informations like a brief summary of the package, the required dependencies to build and run the package, where to get the software package source code and so on. Due to the 1:1 matching between an ebuild file and a software package most of Gentoo and Funtoo developers uses the term ''ebuild'' to designate the  meta-description of a package and the software packages it relates in itself. }}

@@ Line 199: / Line 199: @@
 :package unmasked in SPARC stable '''and current''' trees
 ;<tt>-sparc</tt>
-:package masked in all sparc trees
+:package masked for all sparc trees
 {{ fancyimportant|'''x86''', '''amd64''' or '''sparc''' setting in the ebuild's KEYWORDS will unmask the package for both current and stable tree systems -- that is, any ebuild made available to stable is also made available to unstable. }}