Handbook:Parts/Portage/Branches

From Gentoo Wiki
Jump to:navigation Jump to:search
This page contains changes which are not marked for translation.
Warning
Do not try to follow instructions directly from the Handbook:Parts namespace (WHICH THIS PAGE!), or any of its sub-pages. The Handbook:Parts is a meta handbook used for transcluding text into other Handbooks. Use the architecture-specific Handbooks found in the Handbook list for complete installation instructions.
Parts Handbook
Installation
About the installation
Choosing the media
Configuring the network
Preparing the disks
Installing stage3
Installing base system
Configuring the kernel
Configuring the system
Installing tools
Configuring the bootloader
Finalizing
Working with Gentoo
Portage introduction
USE flags
Portage features
Initscript system
Environment variables
Working with Portage
Files and directories
Variables
Mixing software branches
Additional tools
Custom package repository
Advanced features
Network configuration
Getting started
Advanced configuration
Modular networking
Wireless
Adding functionality
Dynamic management


Using one branch

Stable

The ACCEPT_KEYWORDS variable defines the system's software branch. This variable is set in the /etc/portage/make.conf file and is configured to the stable branch by default. In this instance the default value is amd64.

FILE /etc/portage/make.confUsing the stable branch
# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="amd64"

For a more casual experience, and less risk of instability or other issues, the Handbook recommends staying on the stable software branch. Since this is Portage's default behavior no changes are necessary. System administrators who want to live dangerously or receive the latest possible software updates should read the Testing section.

Testing

Warning
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in a other, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.

In cases where the system administrator would like to run a less-tested software stack, and in exchange receive 'bleeding edge' updates, the testing branch can be selected. To switch to the testing branch, set the ACCEPT_KEYWORDS value to ~amd64.

FILE /etc/portage/make.confUsing the testing branch
# Instructing Portage to use the testing branch (~) for the amd64 architecture.
ACCEPT_KEYWORDS="~amd64"

Any architecture supported by the Gentoo project can move to a testing branch by simply adding a ~ (tilde symbol) in front of the architecture's ACCEPT_KEYWORDS value.

The testing branch is exactly what one would expect - unstable. If a package is in testing, it means that the developers believe it is functional but has not been thoroughly tested. Systems using the testing branch may be the first to encounter bugs in the package. If bugs are discovered, please file a bug report to make the developer(s) aware.

When changing from the stable to the testing branch and performing a @world update, it is normal for many - sometimes hundreds - of packages to be updated to the latest available versions. Updates generally correspond to the upstream project's current release. Keep in mind that, after moving from stable to testing, it may prove a challenge to revert back to the stable branch. This is to be expected.

Mixing stable with testing

package.accept_keywords

It is possible to instruct Portage to allow the testing branch for particular packages, but use the stable branch for the rest of the system. To achieve this, add the package category and name into the /etc/portage/package.accept_keywords file. It is also possible to create a directory (with the same name) and list the package in a file under the directory.

For instance, to use the testing branch for gnumeric:

FILE /etc/portage/package.accept_keywordsUse the testing branch for just the gnumeric application
app-office/gnumeric

Testing particular versions

To use a specific software version from the testing branch but not allow updates from the testing branch for subsequent versions, a specific version of the package can be defined in the package.accept_keywords file. To define a specific version, the = operator is utilized. It is also possible to enter a version range using the <=, <, > or >= operators.

In any case, if any package version information is defined, an operator must be used. Without version information, an operator cannot be used.

In the following Portage is instructed to allow the installation of a specific version of gnumeric, version 1.2.13, even if it is in the testing branch:

FILE /etc/portage/package.accept_keywordsAllow a specific version selection of the gnumeric package
=app-office/gnumeric-1.2.13

Masked packages

package.unmask

Important
Gentoo developers mask packages for good reason, therefore unmasking a package is generally unsupportable by Gentoo's support channels. For this reason, it is to be expected for support requests related to package.unmask and/or package.mask to be ignored or marked as WONTFIX. Please exercise due caution when unmasking packages.

For the next example, presume a package has been masked by the Gentoo developers. When attempting to install the package, Portage will output a message indicating the package has been masked and will generally provide a reason for its masking. Next presume a system administrator, despite the reason mentioned in the package.mask file (situated in /var/db/repos/gentoo/profiles/ by default) still desires to install the package.

To do so, the system administrator would add the target package version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask location.

For instance, if =mail-client/mutt-2.2.9 is masked (poor doggy!), then it can be unmasked by adding the exact same line in the package.unmask location:

FILE /etc/portage/package.unmaskUnmasking a particular version of a package
=mail-client/mutt-2.2.9
Note
If an entry in /var/db/repos/gentoo/profiles/package.mask contains a range of package versions, then it is necessary to unmask only the version(s) that are actually needed. Please read the previous section to learn how to specify versions using operators.

package.mask

It is also possible to instruct Portage to not install a certain package or not update to a specific version of a package. This is called masking a package. To mask a package, add qualifiers as necessary to the /etc/portage/package.mask location (either in that file or in a file in this directory).

For instance, to prevent Portage from installing kernel sources newer than gentoo-sources-4.9.16, add the following line at the package.mask location:

FILE /etc/portage/package.maskMask sys-kernel/gentoo-sources for versions greater than 4.9.16
>sys-kernel/gentoo-sources-4.9.16