/etc/portage/package.accept_keywords

package.accept_keywords and package.keywords are files or directories of files containing definitions for per-package ACCEPT_KEYWORDS statements. They are useful for mixing unstable packages in with a normally stable system packages or vice versa.

These two locations allow ACCEPT_KEYWORDS to be augmented for single packages. If both package.accept_keywords and package.keywords are present, both will be used; values from package.accept_keywords will override values from package.keywords. The package.accept_keywords location is intended to replace the package.keywords location, since profiles support a different form of package.keywords which modifies effective KEYWORDS (rather than ACCEPT_KEYWORDS).

Format and examples

Comment lines begin with # (no inline comments).
One DEPEND atom per line followed by additional KEYWORDS.
Lines without any KEYWORDS imply unstable host arch.

FILE /etc/portage/package.accept_keywordspackage.accept_keywords example

# Always use unstable libgd
media-libs/libgd ~amd64

# Only use stable (LTS) kernel
sys-kernel/gentoo-kernel -~amd64

# Always use unstable netcat
net-analyzer/netcat

Maintenance

Comments

When adding a USE flag or keyword, it is always helpful to leave a comment to why it was set in the first place.

FILE /etc/portage/package.accept_keywords/scummvmp.a_k example

# Using ~amd64 package due to bug XXXX
games-emulation/scummvm

It is generally good practice to use the testing package until the stable version becomes greater than the testing version; then the system would switch back over to tracking the stable package.

FILE /etc/portage/package.use/engrampaExplicitly setting version example

# engrampa 1.28.1 has issues with extracting encrypted zip files
=app-arch/engrampa-1.28.2

~ARCH system-wide

A common trap new and experienced users fall into, is mixing too many stable and testing packages on their system.

If a user has over 100 packages in their /etc/portage/package.accept_keywords, then it's time to think if the user is managing their system correctly or not. One of the main issues of running such a large /etc/portage/package.accept_keywords is that Portage is much more likely to run into conflicts.

Warning
Once a system has been switched to testing, a user cannot simply just downgrade back to stable. Although this can be done, it is highly recommend to reinstall instead.

Some examples:

1. A user is running a stable system where they always want the latest GNOME, Firefox, LibreOffice and Kernel.

  In this case, the user would most likely be better off by switching to a full ~ARCH system.

2. A user is running a stable system and notice the next version of the desktop environment MATE has a fix to an issue they are currently having.

  In this example, the user would pin the MATE dependencies in /etc/portage/package.accept_keywords/mate           (i.e. =mate-base/mate-1.30). This would mean the system would pull all the 1.30 versions from testing and once stable catches up, portage will start tracking the stable branch again.

3. A user has lots of ~ARCH keywords for games or Haskell

  These packages rarely get stable keyword so are fine to run with a stable system in most cases.

Use stable packages on testing systems

Sometimes a user will want a few packages to be stable only. The normally usage case for this is using the kernel with out of tree modules, such as ZFS, where it is recommended to stick to the LTS releases. To do this see the below example:

FILE /etc/portage/package.accept_keywordspackage.accept_keywords example

# Only use stable (LTS) kernel
sys-kernel/gentoo-kernel -~amd64

Additional information

Note: In addition to the normal values from ACCEPT_KEYWORDS package.keywords supports three special tokens:

* - Package is visible if it is stable on any architecture.
~* - Package is visible if it is in testing on any architecture.
** - Package is always visible (KEYWORDS are ignored completely).

Additional note: If you encounter the -* KEYWORD, this indicates that the package is known to be broken on all systems which are not otherwise listed in KEYWORDS. For example, a binary only package which is built for amd64 will look like:

FILE games-fps/quake3-demo-1.11.ebuildBroken on all but amd64 example

KEYWORDS="-* amd64"

To accept this package anyway, use one of the other keywords in package.accept_keywords like this:

FILE /etc/portage/package.accept_keywordsAccept anyways example

games-fps/quake3-demo amd64

Find obsolete entries

Using eix

Using app-portage/eix:

user $eix-test-obsolete

Redundant in /etc/portage/package.{,accept_}keywords:

... considered as REDUNDANT_IF_NO_CHANGE
[I] app-text/pdftk (3.0.0@09/06/2018): gcj-free version of pdftk written in Java
[I] dev-java/commons-lang (3.6(3.6)@03/30/2018): Commons components to manipulate core java classes
Found 2 matches

Using portpeek

Using app-portage/portpeek:

user $portpeek --keyword