|
|
| (27 intermediate revisions by one user not shown) |
| Line 1: |
Line 1: |
| | == Introduction == | | == Introduction == |
| | | | |
| − | {{Project|hosting=http://github.com/funtoo/portage-funtoo}}
| + | Portage is the official package manager of Funtoo Linux. Daniel Robbins maintains a slightly different version from upstream Gentoo Linux, with support for mini-manifests and other features. |
| | | | |
| − | Portage is the official package manager of Funtoo Linux. Daniel Robbins maintains a slightly different version from upstream Gentoo Linux, with support for mini-manifests. | + | == Portage Commands == |
| | | | |
| − | === The recommended way to update your system ===
| + | ; [[emerge]] |
| − | | + | : high-level dependency-based package merge/unmerge tool |
| − | <pre>
| + | ; [[ebuild]] |
| − | # emerge --sync
| + | : lower-level package build tool |
| − | # emerge -auDN world --jobs=3
| + | |
| − | </pre>
| + | |
| | | | |
| − | == Portage Specifications, Changes, News == | + | == Portage Specifications == |
| | | | |
| | The latest progress and changes related to EAPI/PMS and Portage can often be found in the Gentoo Council meeting logs, which are listed on the [http://www.gentoo.org/proj/en/council/ Gentoo Council page]. | | The latest progress and changes related to EAPI/PMS and Portage can often be found in the Gentoo Council meeting logs, which are listed on the [http://www.gentoo.org/proj/en/council/ Gentoo Council page]. |
| Line 18: |
Line 16: |
| | The latest PMS specification to be approved by the Gentoo Council is available: [http://distfiles.gentoo.org/distfiles/pms-3.pdf eapi-3-approved-2010-01-18]. The PMS specification is an attempt to codify the inner workings of Portage, and is authored by Ciaran McCreesh and Stephen Bennett as a Gentoo-hosted project. | | The latest PMS specification to be approved by the Gentoo Council is available: [http://distfiles.gentoo.org/distfiles/pms-3.pdf eapi-3-approved-2010-01-18]. The PMS specification is an attempt to codify the inner workings of Portage, and is authored by Ciaran McCreesh and Stephen Bennett as a Gentoo-hosted project. |
| | | | |
| − | == Emerge Options == | + | == Portage Profiles == |
| | | | |
| − | ; --with-bdeps=y
| + | Portage uses [[Portage Profiles|profiles]] to define settings for various architectures and types of Funtoo/Gentoo systems. See the [[Portage Profiles]] page for detailed information on how Portage handles profiles. |
| − | : This option tells Portage to consider DEPEND for already-installed packages (that are not required to be considered) when updating your system. So when used with <tt>-uDN @world</tt>, the<tt> --with-bdeps=y</tt> option will cause any updated packages listed in DEPEND @world set's ebuilds -- not just those packages being installed/updated -- to be upgraded. However, if any updates are made to a package's DEPEND, it will not cause the specific package(s) containing the DEPEND to be rebuilt, so that they were explicitly built against the packages that were just upgraded. To Daniel Robbins, this seems like a half-step rather than the full upgrade step. It would be preferable if there were an option to cause any parent packages to be rebuilt if anything in DEPEND were upgraded. The reason for this is that if there is a change in DEPEND, then there is the ''potential'' for the parent ebuild to also be affected by these changes in any number of ways. So rebuilding against the most recently-upgraded DEPEND is generally safest.
| + | |
| | | | |
| − | == Ebuild Variable Definitions == | + | == Portage Variables == |
| | | | |
| − | This section builds on information available in the [http://devmanual.gentoo.org/ The Gentoo Developer Guide] and EAPI specifications. We will add information to this section to provide further clarification and details for Funtoo ebuild development.
| + | Portage's behavior can be controlled by a number of configuration settings other variables that can be defined within the ebuild itself. In addition, a number of these variables are defined for the ebuild automatically by Portage. These variables are now documented on their own page: [[Portage Variables]]. |
| − | | + | |
| − | === Path Variables ===
| + | |
| − | | + | |
| − | ;PORTDIR
| + | |
| − | : PORTDIR will be set to the path of the Portage directory that contains the ebuild that is currently executing, such as <tt>/usr/portage</tt>.
| + | |
| − | | + | |
| − | ;PORTAGE_TMPDIR
| + | |
| − | : PORTAGE_TMPDIR defines the path to the location that Portage should use for all its temporary files, and defaults to <tt>/var/tmp</tt>.
| + | |
| − | | + | |
| − | ;DISTDIR
| + | |
| − | : DISTDIR defines the path to the location of all distfiles (downloaded source code/artifacts), and defaults to <tt>/usr/portage/distfiles</tt>.
| + | |
| − | | + | |
| − | ;PKGDIR
| + | |
| − | : PKGDIR defines the path to where Portage will store all built binary packages, and defaults to <tt>/usr/portage/packages</tt>.
| + | |
| − | | + | |
| − | ;RPMDIR
| + | |
| − | : RPMDIR defines the path to where Portage will store all built binary RPM packages, and defaults to <tt>/usr/portage/rpm</tt>.
| + | |
| − | | + | |
| − | ;ROOT
| + | |
| − | :ROOT defines the root of the filesystem to which packages should be installed, and may be set on the command-line. If not defined, Portage will set ROOT to <tt>/</tt> by the time your ebuild executes. When writing <tt>pkg_*</tt> ebuild functions, all your ebuild logic must respect the setting of the ROOT variable and compensate for situations when ROOT is not <tt>/</tt>. ROOT is used by stage1 builds to install to a sub-directory. <tt>ROOT=/tmp/stage1root emerge -e system</tt> is a command that might be run by a stage1 build. After <tt>src_install</tt> executes, Portage will always install the resultant files placed in <tt>$D</tt> to the filesystem defined by ROOT.
| + | |
| − | | + | |
| − | === Prefix Variables ===
| + | |
| − | | + | |
| − | Portage supports the ability to act as a package manager for commercial operating systems such as MacOS X, or to install ebuilds on non-Gentoo systems, or to sub-directories on Gentoo or non-Gentoo systems. When used in this capacity, ebuilds are not installed to the root filesystem but are instead installed to a subdirectory, called a "prefix". Portage's prefix variables, available in EAPI 3, support this capability, and are designed to work with ebuilds that are maintained in a separate [http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay prefix overlay].
| + | |
| − | | + | |
| − | As part of the EAPI 3 prefix support, all ebuild helpers such as <tt>econf</tt> and <tt>einstall</tt> use <tt>$ED</tt> instead of <tt>$D</tt>. See below for full variable definitions.
| + | |
| − | | + | |
| − | ;EPREFIX
| + | |
| − | :This variable is typically set in <tt>/etc/make.conf</tt> or <tt>make.globals</tt>, and defines the prefix that should be used by ebuilds. Prefix-aware ebuilds can reference this variable and use it appropriately. if EPREFIX is not defined, then EPREFIX will default to no value.
| + | |
| − | | + | |
| − | ;EROOT
| + | |
| − | :EROOT is a more concise way of specifying <tt>$ROOT$EPREFIX</tt>, and is intended to be used in <tt>pkg_*</tt> ebuild functions.
| + | |
| − | | + | |
| − | ;ED
| + | |
| − | :ED is a more concise way of specifying <tt>$D$EPREFIX</tt>, and is intended to be used in <tt>src_*</tt> ebuild functions.
| + | |
| − | | + | |
| − | For more information on Portage's prefix support, see the [http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml Gentoo Prefix Techdocs].
| + | |
| − | | + | |
| − | === Path Variables For Your Use ===
| + | |
| − | | + | |
| − | ;WORKDIR
| + | |
| − | :WORKDIR defines the temporary filesystem location that is used for extracting source code/artifacts, preparation, configuration and compilation, and will be defined for you by the time your ebuild executes, and its value must not be modified. By default, <tt>src_unpack</tt> will extract all source code/artifacts within WORKDIR. If you need to manually extract any archives, this must all be done somewhere within WORKDIR, T or D, with WORKDIR being the preferred location for doing this. WORKDIR is automatically cleaned up by Portage upon completion.
| + | |
| − | | + | |
| − | ;S
| + | |
| − | :S defaults to <tt>$WORKDIR/$P</tt>, but may be redefined in your ebuild to be some other sub-directory of WORKDIR. Typically, S may be redefined to reflect the ''real'' directory name that is contained within the source tarball when it differs from the default of <tt>$WORKDIR/$P</tt>. When <tt>src_prepare</tt>, <tt>src_configure</tt>, <tt>src_compile</tt>, <tt>src_test</tt> and <tt>src_install</tt> run, they will attempt to set the current working directory to S if it exists, falling back to WORKDIR if S does not exist.
| + | |
| − | | + | |
| − | ;T
| + | |
| − | :A temporary file storage location that is available to you during your ebuild's execution. T is automatically cleaned up by Portage upon completion.
| + | |
| − | | + | |
| − | ;D
| + | |
| − | :D defines the filesystem tree to which the <tt>src_install</tt> function should install all files. All files defined here will be installed by Portage to the destination defined by ROOT.
| + | |
| − | | + | |
| − | ;FILESDIR
| + | |
| − | : FILESDIR is shorthand for <tt>$PORTDIR/$CATEGORY/$PN/files</tt> -- the <tt>files/</tt> sub-directory in the Portage tree for your particular ebuild. Typically used in <tt>src_prepare</tt> for applying patches, or by <tt>src_install</tt> for installing supplementary files such as initialization scripts that were committed to the Portage tree alongside your ebuild.
| + | |
| − | | + | |
| − | === Metadata Variables ===
| + | |
| − | | + | |
| − | ;EAPI
| + | |
| − | : Periodically, the Gentoo Linux project defines new functionality and behavior related to how ebuilds are handled by Portage. These changes may require you to write your ebuilds slightly differently, or may allow you to take advantage of new capabilities in Portage. In your ebuild, you can specify the EAPI you are targeted by setting the EAPI variable as the first line in the ebuild. If no EAPI is specified, an EAPI of 0 ("classic" behavior) is assumed. To view a complete definition of EAPIs 1 through 3, please see [http://devmanual.gentoo.org/ebuild-writing/eapi/index.html The Gentoo Developer Guide's EAPI page]. Note that the information on EAPI 4 is incomplete, and more detailed information can be found on in-progress [http://dev.gentoo.org/~zmedico/portage/doc/ch05s03s05.html EAPI 4 document maintained by Zac Medico]. At some point, it may be possible to set an EAPI on a repository or overlay-wide basis, but for now, it is set by each individual ebuild.
| + | |
| − | | + | |
| − | ;DEPEND
| + | |
| − | : DEPEND is used to specify an ebuild's build dependencies, and is a list of all ebuilds (and their corresponding versions/slots) that are required to be installed to a bare stage3 (or @system set + dependencies) in order for this package to '''build''' (compile, etc.). If one or more of these ebuilds are not installed, then it must cause the building of this package to fail; otherwise it is not a true build dependency. Do not list any dependencies for packages that are included in the underlying bare stage3 unless specific versions of the core packages (such as gcc, or glibc) are required, since these packages are expected to be available on all systems. All dependencies listed in DEPEND are satisfied '''prior''' to this package being built.
| + | |
| − | | + | |
| − | ;RDEPEND
| + | |
| − | : RDEPEND is used to specify an ebuild's runtime dependencies, and is a list of all ebuilds (and their corresponding versions/slots) that are required to be installed to a bare stage3 (or @system set + dependencies) in order for this package to '''run''' (function). If one or more of these ebuilds are not installed, then it must cause the execution of this package to fail; otherwise it is not a true runtime dependency. Do not list any dependencies for packages that are included in the bare stage3 unless specific versions of the core packages (such as glibc) are required, since these packages are expected to be available on all systems. The dependencies listed in RDEPEND may or not be installed prior to this package being built.
| + | |
| − | | + | |
| − | ; DEPEND ''and'' RDEPEND
| + | |
| − | : Note that if a dependency needs to be available both ''before'' the package is built, and also ''after'' the package is built, then the dependency must be listed in both DEPEND and RDEPEND, as it is both a build and runtime dependency. This is common with many packages, including virtually all shared libraries, which must be installed prior to compilation for headers and linking purposes but must continue to be available after the package is installed so that it can function properly.
| + | |
| − | | + | |
| − | ; (R)DEPEND if installed
| + | |
| − | : It is often useful for an ebuild to conditionally depend on a specific version of another package, if it happens to be installed. Take sys-fs/lvm2 and sys-fs/udev, for example. sys-fs/lvm2 may not always be installed, but sys-fs/udev is a required ebuild. It would be nice if we could specify in the sys-fs/udev ebuild that a specific or higher version of lvm2 is required to work with this particular version of udev, or specify in the lvm2 ebuild that a specific version or higher of udev is required to work with this version of lvm2. While this is not currently possible in Portage, it is possible to use the blocker functionality in Portage to define that earlier versions are ''not'' compatible, which essentially accomplishes the same thing. To specify that another package should not be installed alongside your ebuild, use the double-exclamation from of a blocker: "!!<sys-fs/udev-160" might be an example. This will prevent both ebuilds from being installed on the system at the same time. The double-exclamation blocker is supported in EAPI 2 and above.
| + | |
| − | | + | |
| − | ; IUSE
| + | |
| − | : IUSE specifies the USE variables that are recognized by this ebuild. Note that changing IUSE in existing ebuilds should be handled carefully, as if another ebuild depends on a particular USE variable in IUSE being enabled in your ebuild, and you remove it, then Portage will not be able to satisfy this dependency. Similarly, if another ebuild depends on a particular USE variable in IUSE being disabled in your ebuild, and you remove it, then Portage will no longer be able to satisfy this dependency either. For this reason, it can become difficult to remove USE variables from IUSE once other ebuilds explicitly depend upon them being enabled or disabled.
| + | |
| − | | + | |
| − | ; SRC_URI
| + | |
| − | : SRC_URI contains a list of all remote files that are used by this ebuild during the unpack/prepare/compile/install phases. Starting with EAPI 2, it is possible to rename source tarballs, which comes in handy when pulling down tagged sources from GitHub, using the following trick. This approach also makes it quite easy to release source tarballs for ebuilds, as all you need to do is tag the release and then push the tags to GitHub with a <tt>git push tags</tt> command:
| + | |
| − | | + | |
| − | <source lang="bash">
| + | |
| − | GITHUB_USER="foo"
| + | |
| − | SRC_URI="https://github.com/${GITHUB_USER}/${PN}/tarball/${PV} -> ${PN}-git-${PV}.tgz"
| + | |
| − | | + | |
| − | src_prepare() {
| + | |
| − | cd "${WORKDIR}"/${GITHUB_USER}-${PN}-*
| + | |
| − | S="$(pwd)"
| + | |
| − | }
| + | |
| − | </source>
| + | |
| − | | + | |
| − | === KEYWORDS ===
| + | |
| − | | + | |
| − | KEYWORDS is a general keywording system for ebuilds, but is now used exclusively by the Gentoo architecture teams to define whether a particular ebuild is marked as stable, unstable or masked for a particular system architecture. 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 four values:
| + | |
| − | | + | |
| − | ;<tt>amd64</tt>
| + | |
| − | :64-bit PC-compatible stable tree
| + | |
| − | ;<tt>~amd64</tt>
| + | |
| − | :64-bit PC-compatible unstable tree
| + | |
| − | ;<tt>x86</tt>
| + | |
| − | :32-bit PC-compatible stable tree
| + | |
| − | ;<tt>~x86</tt>
| + | |
| − | :32-bit PC-compatible unstable tree
| + | |
| − | | + | |
| − | An ebuild uses the KEYWORDS variable to control what tree or trees the ebuild is part of, and will contain at most one setting for each system architecture. The KEYWORD settings are defined with the following meaning:
| + | |
| − | | + | |
| − | ;<tt>amd64</tt>
| + | |
| − | :ebuild unmasked in 64-bit PC-compatible stable '''and unstable''' trees
| + | |
| − | ;<tt>~amd64</tt>
| + | |
| − | :ebuild unmasked in 64-bit PC-compatible stable tree only
| + | |
| − | ;<tt>-amd64</tt>
| + | |
| − | :ebuild masked for all 64-bit PC-compatible trees
| + | |
| − | ;<tt>x86</tt>
| + | |
| − | :ebuild unmasked in 32-bit PC-compatible stable '''and unstable''' trees
| + | |
| − | ;<tt>~x86</tt>
| + | |
| − | :ebuild unmasked in 32-bit PC-compatible stable tree only
| + | |
| − | ;<tt>-x86</tt>
| + | |
| − | :ebuild masked for all 32-bit PC-compatible trees
| + | |
| − | | + | |
| − | An important thing to note is that an <tt>x86</tt> or <tt>amd64</tt> setting in the ebuild's KEYWORDS will unmask the ebuild for both unstable and stable tree systems -- that is, any ebuild made available to stable is also made available to unstable.
| + | |
| − | | + | |
| − | Additional wildcard keywords are supported:
| + | |
| − | | + | |
| − | ;<tt>*</tt>
| + | |
| − | : unmask for all trees. This variable can be modified by appending negative keywords: <tt>"* -ia64"</tt> means "all keywords except (~)ia64
| + | |
| − | ;<tt>-*</tt>
| + | |
| − | :mask for all trees. This variable can be modified by appending positive keywords: <tt>"-* amd64 x86"</tt> means "no keywords except for x86 and amd64 stable trees
| + | |
| − | | + | |
| − | ===== 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:
| + | |
| − | | + | |
| − | <source lang="bash">
| + | |
| − | KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd"
| + | |
| − | </source>
| + | |
| | | | |
| | == Multiple ABI Support == | | == Multiple ABI Support == |
| | | | |
| − | Support for multiple ABIs has been partially integrated into Portage and the Gentoo gcc wrapper (part of sys-devel/gcc-config) and has been enabled in some system profiles. This section documents this support so it can be more easily understood.
| + | Portage contains support for multiple ABIs (Application Binary Interfaces) co-existing on the same system. This functionality has been extensively documented and has been moved to its own page: [[Multiple ABI Support]]. |
| − | | + | |
| − | === Core ABI Support ===
| + | |
| − | | + | |
| − | Portage and some system profiles currently contain a very small set of changes so that multiple ABIs can be targeted by Portage. In addition, Gentoo's gcc "wrapper" (part of sys-devel/gcc-config) has a key feature in it to enable this multiple ABI support -- this functionality is detailed later in this section. This implements the core minimal multiple ABI functionality.
| + | |
| − | | + | |
| − | In practice, this capability, combined with the gcc-wrapper's ABI support, can come in handy for directing Portage to build libraries for the non-default ABI, using the appropriate directories so that this ebuild can be manually installed on your system without writing the libraries for the default ABI. An example of this approach is documented later in this section. This support is also useful when it is necessary to build 32-bit versions of some applications that may not be compatible with 64-bit multilib systems, and also allows for the possibility of an ebuild compiling both 32-bit and 64-bit versions of certain applications when necessary.
| + | |
| − | | + | |
| − | ==== Core ABI: econf() ====
| + | |
| − | | + | |
| − | Portage's <tt>econf()</tt> function has support for automatically specifying the proper <tt>--libdir=</tt> setting to <tt>configure</tt> based on settings that are found in the system profile. The algorithm is documented as "Algorithm 9" in the PMS specification. The intended purpose of automatically setting <tt>--libdir=</tt> is designed so that 64-bit libraries will be installed into /usr/lib64 on multilib systems, and 32-bit libraries will be installed into /usr/lib32 on multilib systems, rather than simply installing these libraries into /usr/lib.
| + | |
| − | | + | |
| − | While this functionality has questionable value for most normal ebuilds (since a library installed into /usr/lib will work just as well as one installed into /usr/lib64 on an amd64 multilib system,) this functionality likely comes in handy when building the app-emulation/emul-linux-x86-* binary library bundles to support 32-bit applications, as it allows the ABI to be set in the environment, and in combination with the gcc wrapper will cause 32-bit libraries to be built and installed to /usr/lib32.
| + | |
| − | | + | |
| − | ==== Core ABI: Gcc Wrapper ====
| + | |
| − | | + | |
| − | It is important to note that Gentoo Linux uses a ''gcc wrapper'' as a front-end for all calls to gcc, and this wrapper is part of the sys-devel/gcc-config ebuild. One of the features of the wrapper is that it looks for ABI being defined in the environment, and if it is, it will automatically ensure that the CFLAGS value that the compiler sees is actually the setting of CFLAGS_$ABI in the environment, which originates from the system profile. On amd64 multilib systems, this means that a call to <tt>ABI="x86" gcc</tt> will result in the compiler being passed an extra "-m32" option to force 32-bit code. This -m32 option will generally not appear in the build log, so it may be confusing for developers. This is a critical component of the multiple ABI support in Gentoo and Funtoo Linux.
| + | |
| − | | + | |
| − | ==== Core ABI: Working Together ====
| + | |
| − | | + | |
| − | The algorithm used by <tt>econf()</tt> works as follows. A system profile (or the user, via the environment) will set the ABI variable to a value like <tt>amd64</tt> or <tt>x86</tt>. A corresponding ABI-specific variable named <tt>LIBDIR_$ABI</tt> (i.e. <tt>LIBDIR_x86</tt>) will be used from the system profile, and will be set to either <tt>lib32</tt>, <tt>lib64</tt> or <tt>lib</tt>. This will be used to define the target <tt>--libdir</tt> setting used by <tt>econf()</tt>. This will allow the system profile to direct exactly where libraries are installed when building them for a particular ABI, as long as the ebuild writer usese <tt>econf()</tt> (part of core Portage) or <tt>get_libdir()</tt> (part of <tt>multilib.eclass</tt>.)
| + | |
| − | | + | |
| − | In addition, the ABI variable is set in the environment will cause the gcc-wrapper will adjust its <tt>CFLAGS</tt> settings, by using <tt>CFLAGS_$ABI</tt> to tell the multilib-aware gcc to target the alternate ABI. With ABI="x86" on amd64 multilib systems, this will cause CFLAGS to have an <tt>-m32</tt> to be appended to it, to instruct the compiler to produce 32-bit code.
| + | |
| − | | + | |
| − | ==== Core ABI: Demonstration ====
| + | |
| − | | + | |
| − | To test the multiple ABI functionality on an amd64 multilib system, you can execute the following command:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | # ABI="x86" emerge --buildpkgonly sys-libs/zlib
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | If you compare the libz shared library in the resultant .tbz2 package ot the one installed in /lib64, you'll note that the one in the .tbz2 is 32-bit while the one in /lib64 is 64-bit:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | ninja1 lib32 # file libz.so.1.2.5
| + | |
| − | libz.so.1.2.5: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
| + | |
| − | ninja1 lib32 # file /lib/libz.so.1.2.5
| + | |
| − | /lib/libz.so.1.2.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | It is important to note that Gentoo's gcc wrapper (part of sys-devel/gcc-config) instructs gcc to produce 32-bit code by silently passing (not visible in the build output, due to the wrapper design)a <tt>-m32</tt> option to all compiler calls.
| + | |
| − | | + | |
| − | Note that you should not install the 32-bit zlib .tbz2 package on a 64-bit multilib system, as it will replace the critical 64-bit zlib binaries on your system. Portage's /var/db/pkg database does not allow side-by-side installations of packages that were built against different ABIs. However, this Portage functionality can be used to build 32-bit libraries when needed, which can be installed via manual extraction of the resultant .tbz2 file to the root filesystem.
| + | |
| − | | + | |
| − | === Extended ABI Support ===
| + | |
| − | | + | |
| − | Beyond the core functionality, the <tt>multilib.eclass</tt> (which is inherited as part of the ubiquitous <tt>eutils.eclass</tt>) contains a more significant set of code to support multiple ABIs, which appears to be designed to be eventually merged into the Portage core. This means that latent multiple ABI support is available in Portage and can be used without inheriting <tt>multilib.eclass</tt> for "regular" ebuilds, but ebuilds that need more control over the ABI configuration can inherit <tt>multilib.eclass</tt> for access to a significant number of helper functions. If you want to use <tt>multilib.eclass</tt>, first familiarize yourself with the changes in Portage that exist that support <tt>multilib.eclass</tt> functionality, which are documented in this section. Then you will have a much easier time understanding <tt>multilib.eclass</tt>.
| + | |
| − | | + | |
| − | ==== ABI Profile Variables ====
| + | |
| − | | + | |
| − | ; ARCH
| + | |
| − | : ARCH defines the name for the underlying system architecture. As of late December 2010, Gentoo Linux supports defines the following architectures in various system profiles:
| + | |
| − | | + | |
| − | <tt>alpha
| + | |
| − | amd64
| + | |
| − | amd64-fbsd
| + | |
| − | arm
| + | |
| − | cobalt
| + | |
| − | fulong-2e
| + | |
| − | hppa
| + | |
| − | hppa-hpux
| + | |
| − | ia64
| + | |
| − | ia64-hpux
| + | |
| − | ip22
| + | |
| − | ip27
| + | |
| − | ip28
| + | |
| − | ip30
| + | |
| − | ip32
| + | |
| − | ip32r10k
| + | |
| − | m68k
| + | |
| − | m68k-mint
| + | |
| − | mips
| + | |
| − | mips-irix
| + | |
| − | mips64
| + | |
| − | mips64el
| + | |
| − | mipsel
| + | |
| − | ppc
| + | |
| − | ppc-aix
| + | |
| − | ppc-macos
| + | |
| − | ppc-openbsd
| + | |
| − | ppc64
| + | |
| − | ppc64-macos
| + | |
| − | s390
| + | |
| − | sgi
| + | |
| − | sh
| + | |
| − | sparc
| + | |
| − | sparc-fbsd
| + | |
| − | sparc-solaris
| + | |
| − | sparc64
| + | |
| − | sparc64-fbsd
| + | |
| − | sparc64-solaris
| + | |
| − | x64-macos
| + | |
| − | x64-openbsd
| + | |
| − | x64-solaris
| + | |
| − | x86
| + | |
| − | x86-cygwin
| + | |
| − | x86-fbsd
| + | |
| − | x86-interix
| + | |
| − | x86-macos
| + | |
| − | x86-netbsd
| + | |
| − | x86-openbsd
| + | |
| − | x86-solaris
| + | |
| − | x86-winnt
| + | |
| − | xbox
| + | |
| − | yeeloong</tt>
| + | |
| − | | + | |
| − | This list was generated using the following command:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | # cd /usr/portage/profiles
| + | |
| − | # grep -r ARCH= * | cut -f2 -d"=" | sed -e 's/"//g' | sort -u
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | The following variables are supported on a limited number of architectures - namely, those that have different ABIs available. These include Sparc, PowerPC and PC-compatible x86/amd64 architectures.
| + | |
| − |
| + | |
| − | ; ABI
| + | |
| − | : Defines the name of the current ABI for which packages should be built. This variable is recognized by the gcc wrapper - see "Core gcc wrapper ABI support", below.
| + | |
| − | | + | |
| − | ; DEFAULT_ABI
| + | |
| − | : Defines the name of the default ABI for which packages should be built.
| + | |
| − | | + | |
| − | ; MULTILIB_ABIS
| + | |
| − | : This consists of a space-separated string of one or more ABIs that are supported on the current system. Amd64 multilib systems will have this set to <tt>amd64 x86</tt>
| + | |
| − | | + | |
| − | | + | |
| − | ==== ABI-Specific Profile Variables ====
| + | |
| − | | + | |
| − | These variables have a suffix (represented below by <tt>*</tt>) that is set based on the ABI that the particular setting is for. For example, <tt>LIBDIR_amd64</tt> would set the library directory name for the amd64 ABI. The rationale for this naming convention is that it allows settings for multiple architectures to be defined together in a single file, and multiple ABI settings to exist on a system that may support multiple ABIs.
| + | |
| − | | + | |
| − | ; LIBDIR_*
| + | |
| − | | + | |
| − | ; CHOST_*
| + | |
| − | | + | |
| − | ; CDEFINE_*
| + | |
| − | | + | |
| − | ; CFLAGS_*
| + | |
| − | : Note: this variable is used by the gcc wrapper when ABI is defined in the environment.
| + | |
| − | | + | |
| − | ; LDFLAGS_*
| + | |
| − | | + | |
| − | ; ASFLAGS_*
| + | |
| − | | + | |
| − | ==== multilib.eclass ====
| + | |
| − | | + | |
| − | Note that a number of these functions can probably be replaced with enhanced profile settings, as all they do is spit out canned values based on the setting of one variable or another. They are also prime candidates for inclusion into the Portage core, possibly with some reworking or deprecation so that as many of these as possible are replaced with "dead" variables rather than "live" code.
| + | |
| − | | + | |
| − | ; has_multilib_profile()
| + | |
| − | : This is a boolean function that returns 0 (true) if multiple ABIs are defined in the MULTILIB_ABIS variable; otherwise 1 (false).
| + | |
| − | | + | |
| − | ; get_libdir()
| + | |
| − | : Returns the "lib" directory name to use, based on the current setting of ABI. For example, on amd64 multilib systems, this will typically return <tt>lib64</tt>, and is typically used in <tt>src_configure()</tt> like this: <tt>./configure --libdir=/usr/$(get_libdir)</tt>.
| + | |
| − | | + | |
| − | ; get_modname()
| + | |
| − | : Used by some ebuilds that generate dynamically-loadable modules, called "bundles" on MacOS X. ELF (used by Linux) makes no differentiation between the handling of shared libraries and loadable modules (or their file extension, which is ".so",) but Mach (MacOS X) does. MacOS X bundles cannot be linked against, but can be dynamically loaded using the dyld API. Apple also recommends that they have an extension of ".bundle" rather than ".so". This function will return ".bundle" for Darwin (Mach) systems, and ".so" for everything else. For more information, see [http://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm MacOS X Guide For Unix Geeks].
| + | |
| − | | + | |
| − | ; get_libname()
| + | |
| − | : Used by a handful of ebuilds to determine the proper suffix for shared libraries on the current system. This function has various hard-coded values depending on the value of CHOST. For example, Darwin systems will get an echoed value of "<tt>.dylib</tt>" while Linux systems will get a value of "<tt>.so</tt>". Accepts an optional version argument that will be properly appended to the output.
| + | |
| − | | + | |
| − | ; multilib_env()
| + | |
| − | : Used by toolchain.eclass, gnatbuild.eclass and the glibc ebuild - sets up environment variables for using a cross-compiler. Accepts a single argument - the target architecture in GNU format.
| + | |
| − | | + | |
| − | ; multilib_toolchain_setup()
| + | |
| − | : In practice, this function is used exclusively to target a non-default x86 ABI on amd64 multilib systems. It accepts one argument, the name of an ABI, or <tt>default</tt> as a shorthand for the default system ABI. It will configure environment variables so the x86 (or other) compiler is targeted, and also backs up all modified variables so they can be restored later. It is typically used to allow non-64-bit-compatible code to still be installed on amd64 multilib systems, by adding the following to the top of <tt>src_configure()</tt>:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | src_configure() {
| + | |
| − | use amd64 && multilib_toolchain_setup x86
| + | |
| − | # we're now building a 32-bit app on a 64-bit system, whee!
| + | |
| − | econf
| + | |
| − | }
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | === ABI Support Limitations ===
| + | |
| − | | + | |
| − | Only a handful of applications leverage the more sophisticated functionality available in <tt>multilib.eclass</tt>, and Gentoo Linux currently uses binary bundles of 32-bit libraries to provide support for 32-bit applications on 64-bit multilib systems, rather than using Portage functionality to build these components from source. One possible explanation for this approach is that Portage currently does not allow applications to be slotted on ABI -- that is, a 32-bit and 64-bit version of sys-libs/zlib cannot co-exist in the Portage /var/db/pkg database, even if they do not overwrite one another on the filesystem when installed. There may be other possible reasons why building 32-bit packages from source remains unfeasible in Gentoo Linux, and will be documented here as they are discovered.
| + | |
| | | | |
| | == Ebuild Functions == | | == Ebuild Functions == |
| | | | |
| − | Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. These functions are defined below:
| + | An ebuild developer has the ability to define [[Ebuild Functions]] that define steps to perform during a particular part of the ebuild lifecycle. These steps are now documented on their own page: [[Ebuild Functions]]. |
| | | | |
| − | === src_* functions === | + | == Funtoo Portage Development == |
| | | | |
| − | Ebuild functions starting with <tt>src_</tt> are all related to creating the ebuild or package from source code/artifacts, and are defined below:
| + | The Funtoo Core Team is currently working on a general-purpose plug-in system so that the GNU info file regeneration, news update display, and scanning of files that need updating in /etc can be pulled out of the official Portage emerge code. In addition, this plug-in system will allow other types of things to be hooked into various phases of emerge. This will allow various new plug-ins to be developed and used on systems, such as periodic security checks, etc. |
| | | | |
| − | ==== src_unpack ==== | + | === TODO === |
| | | | |
| − | <tt>src_unpack</tt> is intended to be used to unpack the source code/artifacts that will be used by the other <tt>src_*</tt> functions. With EAPI 1 and earlier, it is also used for patching/modifying the source artifacts to prepare them for building, but with EAPI 2 or later the <tt>src_prepare</tt> function should be used for this instead. When <tt>src_unpack</tt> starts, the current working directory is set to <tt>$WORKDIR</tt>, which is the directory within which all source code/artifacts should be expanded. Note that the variable <tt>$A</tt> is set to the names of all the unique source files/artifacts specified in <tt>SRC_URI</tt>, and they will all be available in <tt>$DISTDIR</tt> by the time <tt>src_unpack</tt> starts. Also note that if no <tt>src_unpack</tt> function is specified, <tt>ebuild.sh</tt> will execute the following function for <tt>src_unpack</tt> by default:
| + | Add support to portage, so that when an ebuild is merged, the /var/db/pkg entry contains a list of all currently-installed versions of all ebuilds upon which that ebuild RDEPENDs. This, combined with a comprehensive set of past USE settings (may need to implement this too,) can be used to detect when an ebuild needs to be rebuilt. This could help to address issues like those in [http://bugs.gentoo.org/167662 Gentoo Bug 167662] and allow easier implementation of support for things like perl-cleaner. Currently, perl-cleaner doesn't detect that vim uses perl and moving from -ithreads to ithreads causes vim to die, so it needs to be manually rebuilt. |
| | | | |
| − | <pre>
| + | Add support for portage to understand which version of a particular app is the "active" version that it was built against, and record this information in /var/db/pkg. This can help to implement perl-cleaner-like support in Portage. |
| − | src_unpack() {
| + | |
| − | unpack ${A}
| + | |
| − | }
| + | |
| − | </pre>
| + | |
| | | | |
| − | ==== src_prepare ==== | + | == Funtoo Features/Changes == |
| | | | |
| − | EAPI 2 and above support the <tt>src_prepare</tt> function, which is intended to be used for applying patches or making other modifications to the source code. When <tt>src_prepare</tt> starts, the current working directory is set to <tt>$S</tt>.
| + | === Summary === |
| | | | |
| − | ==== src_configure ====
| + | In [https://github.com/funtoo/portage-funtoo/tree/thin-manifest the thin-manifest branch], Funtoo changes have been isolated into the following commits: |
| − | | + | |
| − | EAPI 2 and above support the <tt>src_configure</tt> function, which is used to configure the source code prior to compilation. With EAPI 2 and above, the following default <tt>src_configure</tt> is defined if none is specified:
| + | |
| | | | |
| | <pre> | | <pre> |
| − | src_configure() {
| + | e5a6649e094eb7230aa8f56d97fe303f77b158e9 preserve bindist through use expansion |
| − | if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
| + | 5a092fdae8afbff679350dc5d8818e10ab35fd80 safetydance feature |
| − | econf
| + | 16887ddce712da8b61887f9bce70e19b95e75c25 core funtoo git-sync implementation |
| − | fi
| + | 2c6e2b427a2aa179b61667caf89497818ec34ae2 run pwconv and grpconv after emerge completes to ensure /etc/shadow and /etc/gshadow are valid. |
| − | }
| + | ea565da9ab5f54580f66814a17aca39d8e568732 funtoo-specific man page changes |
| | + | c8f130fa4b332d87f2202ddaf0222b89018914d0 Funtoo config file changes. This includes stuff related to rsync as well as /lib/firmware |
| | + | dba5a350e16043a6ff6281ea80fc02c8f56efd4f remove emerge-webrsync -- not supported in funtoo |
| | + | 0d9dda7b2b3165b268545e3e8eb44aa8d3c20a57 small ebuild.sh fix to not source any stray directories |
| | + | 8500043b3075d26c77a7ec1b8c2745373ca0c3b5 disable warning for use of *, -* in KEYWORDS |
| | + | 86ed81605e73b8b6d6b06fc60a9a0bc0c13ee429 protect firmware as well as modules |
| | + | e7b6512e582fbcd9af0eb82c617549b101c8ae97 slashbeast's localpatch feature |
| | + | 5af34ad9334310c0926e52d9e1801ee170e12184 simplify path setting in ebuild.sh by using getpath() function |
| | + | 42789a70184343008c4cb1fe20bc4398e881d285 remove bin/ebuild-helpers/sed |
| | </pre> | | </pre> |
| | | | |
| − | ==== src_compile ====
| + | These commits do not yet include the unified-path/funtoo-profile 1.0 patches. |
| | | | |
| − | This function defines the steps necessary to compile source code. With EAPI 1 and earlier, this function is also used to configure the source code prior to compilation. However, starting with EAPI 2, the <tt>src_configure</tt> function must be used for configuration steps instead of bundling them inside <tt>src_compile</tt>. In addition, starting with EAPI 2, there is now a default <tt>src_compile</tt> function that will be executed if none is defined in the ebuild:
| + | === In Funtoo stable/current Portage === |
| − | | + | |
| − | <pre>
| + | |
| − | src_compile() {
| + | |
| − | if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ] ; then
| + | |
| − | emake || die "emake failed"
| + | |
| − | fi
| + | |
| − | }
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | ==== src_test ==== | + | |
| − | | + | |
| − | <tt>src_test</tt> is an interesting function - by default, an end-user's Portage does not have tests enabled. But if a user has <tt>test</tt> in <tt>FEATURES</tt>, or <tt>EBUILD_FORCE_TEST</tt> is defined, then <tt>ebuild.sh</tt> will attempt to run a test suite for this ebuild, by executing <tt>make check</tt> or <tt>make test</tt> if these targets are defined in the Makefile; otherwise, no tests will execute. If your Makefile supports <tt>make check</tt> or <tt>make test</tt> but the test suite is broken, then specify <tt>RESTRICT="test"</tt> in your ebuild to disable the test suite.
| + | |
| − | | + | |
| − | ==== src_install ====
| + | |
| − | | + | |
| − | <tt>src_install</tt> is used by the ebuild writer to install all to-be-installed files to the <tt>$D</tt> directory, which can be treated like an empty root filesystem, in that <tt>${D}/usr</tt> is the equivalent of the <tt>/usr</tt> directory, etc. When <tt>src_install</tt> runs, the Portage sandbox will be enabled, which will prevent any processes from creating or modifying files outside of the <tt>${D}</tt> filesystem tree, and a sandbox violation will occur (resulting in the termination of the ebuild) if any such sandbox violation should occur. Once <tt>src_install</tt> has perfomed all necessary steps to install all to-be-installed files to <tt>$D</tt>, Portage will take care of merging these files to the filesystem specified by the <tt>$ROOT</tt> environment variable, which defaults to <tt>/</tt> if not set. When Portage merges these files, it will also record information about the installed package to <tt>/var/db/pkg/(cat)/$P</tt>. Typically, a <tt>src_install</tt> function such as this is sufficient for ensuring that all to-be-installed files are installed to <tt>$D</tt>:
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | src_install() {
| + | |
| − | make DESTIDR="$D" install
| + | |
| − | }
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | === pkg_* functions ===
| + | |
| − | | + | |
| − | An ebuild's functions starting with <tt>pkg_*</tt> take a wider view of the package lifecycle, and may be executed very early or very late in the build or package installation process. They are also all executed even if installing a Portage binary package, so are the intended place for defining any global configuration changes that are also required during binary package installation, such as user and group creation. When these functions are executed, the <tt>$ROOT</tt> variable will be defined to point to the target root filesystem to which the package is to be (or has been) installed. All logic inside <tt>pkg_*</tt> functions must function properly even if <tt>$ROOT</tt> is something other than <tt>/</tt>.
| + | |
| − | | + | |
| − | ==== pkg_setup ====
| + | |
| − | | + | |
| − | The <tt>pkg_setup</tt> function is unusual in that it runs prior to any <tt>src_*</tt> function, and also runs prior to any other <tt>pkg_*</tt> function that runs when a binary package is installed, so it provides a useful place for the ebuild writer to perform any sanity checks, global configuration changes to the system (such as user/group creation) or set any internal global variables that are used by the rest of the ebuild. Using this function for defining global variables that are needed in multiple other functions is a useful way of avoiding duplicate code. You should also look to <tt>pkg_setup</tt> as the ideal place to put any logic that would otherwise linger in the main body of the ebuild, which should be avoided at all costs as it will slow down dependency calculation by Portage. Also remember that Portage can build binary packages, and this function is a good place to execute any steps that are required to run both prior to building an ebuild, and prior to installing a package. Also consider using <tt>pkg_preinst</tt> and <tt>pkg_postinst</tt> for this purpose.
| + | |
| − | | + | |
| − | ==== pkg_pretend ====
| + | |
| − | | + | |
| − | The <tt>pkg_pretend</tt> function was added with EAPI 3, and it's the opinion of Daniel Robbins that the use of this function should be avoided. This function is especially unusual in that it is intended to be run ''during dependency calculation'', and is intended to provide a polite mechanism to inform the user that a particular ebuild will fail due to a known incompatibility, typically a kernel incompatibility. That way, the user can know during <tt>emerge --pretend</tt> that a merge will fail. While this is useful, extending the dependency engine using <tt>bash</tt> is a very low-performance means to perform these tests. Therefore, The Funtoo core team recommends against using <tt>pkg_pretend</tt>. An extensible dependency engine would be a more appropriate and high-performance way to provide identical functionality.
| + | |
| − | | + | |
| − | ==== pkg_preinst ====
| + | |
| − | | + | |
| − | The <tt>pkg_preinst</tt> function is called by Portage, prior to merging the to-be-installed files to the target filesystem specified by <tt>$ROOT</tt> environment variable (which defaults to <tt>/</tt>.) Keep in mind that these to-be-installed files were either just compiled and installed to <tt>$D</tt> by <tt>src_install</tt>, or they were just extracted from a <tt>.tbz2</tt> binary package. The <tt>pkg_preinst</tt> function provides an ideal place to perform any "just before install" actions, such as user and group creation or other necessary steps to ensure that the package merges successfully. It also provides a potential place to perform any sanity checks related to installing the package to the target filesystem. If any sanity checks fail, calling <tt>die</tt> from this function will cause the package to not be installed to the target filesystem.
| + | |
| − | | + | |
| − | ==== pkg_postinst ====
| + | |
| − | | + | |
| − | The <tt>pkg_postinst</tt> function is called by Portage prior to the package being installed to the target filesystem specified by <tt>$ROOT</tt>. This is a good place to perform any post-install configuration actions as well as print any informational messages for the user's benefit related to the package that was just installed.
| + | |
| − | | + | |
| − | ==== pkg_prerm ====
| + | |
| − | | + | |
| − | The <tt>pkg_prerm</tt> function is called by Portage before an ebuild is removed from the filesystem.
| + | |
| − | | + | |
| − | ==== pkg_postrm ====
| + | |
| − | | + | |
| − | The <tt>pkg_postrm</tt> function is called by Portage after an ebuild is removed from the filesystem.
| + | |
| − | | + | |
| − | === Extra pre_ and post_ functions ===
| + | |
| − | | + | |
| − | Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.
| + | |
| − | | + | |
| − | === Helper Functions ===
| + | |
| − | | + | |
| − | ;econf()
| + | |
| − | : econf() is part of ebuild.sh and was originally intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure</tt> stage. Currently, econf() is ~84 lines and its behavior changes depending upon which EAPI you happen to be using. For this reason, the use of econf() is strongly discouraged at this time, and the Funtoo Linux core team recommends that you call ./configure directly.
| + | |
| − | | + | |
| − | == Funtoo Portage Development ==
| + | |
| − | | + | |
| − | The Funtoo Core Team is currently working on a general-purpose plug-in system so that the GNU info file regeneration, news update display, and scanning of files that need updating in /etc can be pulled out of the official Portage emerge code. In addition, this plug-in system will allow other types of things to be hooked into various phases of emerge. This will allow various new plug-ins to be developed and used on systems, such as periodic security checks, etc.
| + | |
| − | | + | |
| − | == Funtoo Features/Changes ==
| + | |
| | | | |
| | ;emerge --sync from git | | ;emerge --sync from git |
| − | :If a git-based Portage tree is already in place, <tt>emerge --sync</tt> will run "git pull" to update the underlying Portage tree. | + | :If a git-based Portage tree is already in place, <tt>emerge --sync</tt> will run "git pull" to update the underlying Portage tree. If one is not in place, the contents of the SYNC variable will be used as the remote URI from which to clone a git tree (2.2). In addition, SYNC_USER and SYNC_UMASK (defaulting to root and 022) can be used to define the user account to use for cloning/syncing, as well as the umask to use. (2.2). |
| | | | |
| | ;Sed Wrapper Symlink and PATH fix | | ;Sed Wrapper Symlink and PATH fix |
| Line 448: |
Line 75: |
| | | | |
| | ;mini-manifest | | ;mini-manifest |
| − | :Funtoo's Portage supports a special mode of operation where Manifests only contain digests for distfiles and not for files in the Portage tree. This is to eliminate redundant digests since git already provides SHA1 digests. This feature is currently enabled by adding "mini-manifest" to FEATURES in /etc/make.conf but the intention is to eventually move it to a repo-specific option. Funtoo provides a special "mini-manifest" tree that is smaller than the full-size Portage tree, and is intended to be used with the mini-manifest feature. | + | :Funtoo's Portage supports a special mode of operation where Manifests only contain digests for distfiles and not for files in the Portage tree. This is to eliminate redundant digests since git already provides SHA1 digests. This feature is currently enabled by adding "mini-manifest" to FEATURES in /etc/make.conf but the intention is to eventually move it to a repo-specific option (note: this has now been done, as "thin-manifest" functionality has been integrated into recent versions of Portage, and is being beta tested in Funtoo.) Funtoo provides a special "mini-manifest" tree that is smaller than the full-size Portage tree, and is intended to be used with the mini-manifest feature. |
| | | | |
| | ;preserve bindist through USE filtering | | ;preserve bindist through USE filtering |
| Line 465: |
Line 92: |
| | :There are several ebuilds in the Gentoo Portage repository that use .xz files but do not explicitly depend on xz-utils. A workaround has been added to ebuild.sh to add this dependency to metadata automatically if a .xz file exists in SRC_URI. This change is not yet in the official Portage sources but is being used on the Funtoo side when generating our git-based Portage trees. | | :There are several ebuilds in the Gentoo Portage repository that use .xz files but do not explicitly depend on xz-utils. A workaround has been added to ebuild.sh to add this dependency to metadata automatically if a .xz file exists in SRC_URI. This change is not yet in the official Portage sources but is being used on the Funtoo side when generating our git-based Portage trees. |
| | | | |
| − | == Commands ==
| |
| − |
| |
| − | ; emerge
| |
| − | : high-level dependency-based package merge/unmerge tool
| |
| − | ; ebuild
| |
| − | : lower-level package build tool
| |
| − | <issues/>
| |
| | [[Category:Projects]] | | [[Category:Projects]] |
| | + | [[Category:Portage]] |
Portage is the official package manager of Funtoo Linux. Daniel Robbins maintains a slightly different version from upstream Gentoo Linux, with support for mini-manifests and other features.
The latest progress and changes related to EAPI/PMS and Portage can often be found in the Gentoo Council meeting logs, which are listed on the Gentoo Council page.
Portage's behavior can be controlled by a number of configuration settings other variables that can be defined within the ebuild itself. In addition, a number of these variables are defined for the ebuild automatically by Portage. These variables are now documented on their own page: Portage Variables.
Portage contains support for multiple ABIs (Application Binary Interfaces) co-existing on the same system. This functionality has been extensively documented and has been moved to its own page: Multiple ABI Support.
The Funtoo Core Team is currently working on a general-purpose plug-in system so that the GNU info file regeneration, news update display, and scanning of files that need updating in /etc can be pulled out of the official Portage emerge code. In addition, this plug-in system will allow other types of things to be hooked into various phases of emerge. This will allow various new plug-ins to be developed and used on systems, such as periodic security checks, etc.
Add support to portage, so that when an ebuild is merged, the /var/db/pkg entry contains a list of all currently-installed versions of all ebuilds upon which that ebuild RDEPENDs. This, combined with a comprehensive set of past USE settings (may need to implement this too,) can be used to detect when an ebuild needs to be rebuilt. This could help to address issues like those in Gentoo Bug 167662 and allow easier implementation of support for things like perl-cleaner. Currently, perl-cleaner doesn't detect that vim uses perl and moving from -ithreads to ithreads causes vim to die, so it needs to be manually rebuilt.
Add support for portage to understand which version of a particular app is the "active" version that it was built against, and record this information in /var/db/pkg. This can help to implement perl-cleaner-like support in Portage.
