User:Zen desu/installing base

Configuring Portage

Installing a Gentoo ebuild repository snapshot from the web

Before portage can be used to emerge packages, an up-to-date ebuild repository must be obtained. Portage uses ebuilds and eclasses to build and install packages. Additionally, ebuild repositories contain profile definitions and news items.

Note
Once the local ebuild repository has been updated, Portage may recommend upgrading certain packages. These updates will be installed later, after the system profile has been selected, and the system make.conf has been configured.

Using emerge-webrsync

emerge-webrsync can be used to download a daily snapshot of the Gentoo ebuild repository:

root #emerge-webrsync

Tip
When limited by bandwidth, or behind a very restricted firewall, using emerge-webrsync may be preferred to emerge --sync.

Note
When run for the first time, emerge-webrsync may complain about a missing / location. This can be ignored, as the directory will be automatically created.

Using emerge --sync

In situations where the most recent repositories are required, and there are no network limitations, emerge --sync can be used.

By default, emerge --sync will use rsync to update the local repositories:

root #emerge --sync

Tip
On slow terminals, such as certain frame buffers or serial consoles, --quiet can be used to speed up the sync.

Note
webrsync sources are updated daily, while rsync sources are updated hourly. There is generally no need to sync repos more than once a day.

Optional: Selecting mirrors

In order to download source code quickly it is recommended to select a fast, geographically close mirror. Portage will look in the make.conf file for the GENTOO_MIRRORS variable and use the mirrors listed therein. It is possible to surf to the Gentoo mirror list and search for a mirror (or multiple mirrors) close to the system's physical location (as those are most frequently the fastest ones).

A tool called mirrorselect provides a pretty text interface to more quickly query and select suitable mirrors. Just navigate to the mirrors of choice and press Spacebar to select one or more mirrors.

root #emerge --ask --verbose --oneshot app-portage/mirrorselect

root #mirrorselect -i -o >> /etc/portage/make.conf

Alternatively, a list of active mirrors are available online.

Optional: Updating the Gentoo ebuild repository

It is possible to update the Gentoo ebuild repository to the latest version. The previous emerge-webrsync command will have installed a very recent snapshot (usually recent up to 24h) so this step is definitely optional.

Suppose there is a need for the latest package updates (up to 1 hour), then use emerge --sync. This command will use the rsync protocol to update the Gentoo ebuild repository (which was fetched earlier on through emerge-webrsync) to the latest state.

root #emerge --sync

On slow terminals, such as certain frame buffers or serial consoles, it is recommended to use the --quiet option to speed up the process:

root #emerge --sync --quiet

Reading news items

When the Gentoo ebuild repository is synchronized, Portage may output informational messages similar to the following:

* IMPORTANT: 2 news items need reading for repository 'gentoo'.

* Use eselect news to read news items.

News items were created to provide a communication medium to push critical messages to users via the Gentoo ebuild repository. To manage them, use eselect news. The eselect application is a Gentoo-specific utility that allows for a common management interface for system administration. In this case, eselect is asked to use its news module.

For the news module, three operations are most used:

• With list an overview of the available news items is displayed.
• With read the news items can be read.
• With purge news items can be removed once they have been read and will not be reread anymore.

root #eselect news list

root #eselect news read

More information about the news reader is available through its manual page:

root #man news.eselect

Choosing the right profile

Tip
Desktop profiles are not exclusively for desktop environments. They are also suitable for minimal window managers like i3 or sway.

A profile is a building block for any Gentoo system. Not only does it specify default values for USE, CFLAGS, and other important variables, it also locks the system to a certain range of package versions. These settings are all maintained by Gentoo's Portage developers.

To see what profile the system is currently using, run eselect using the profile module:

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux// *
  [2]   default/linux///desktop
  [3]   default/linux///desktop/gnome
  [4]   default/linux///desktop/kde

Note
The output of the command is just an example and evolves over time.

Note
To use systemd, select a profile which has "systemd" in the name and vice versa, if not

There are also desktop sub-profiles available for some architectures which include software packages commonly necessary for a desktop experience.

Warning
Profile upgrades are not to be taken lightly. When selecting the initial profile, use the profile corresponding to the same version as the one initially used by the stage file (e.g. ). Each new profile version is announced through a news item containing migration instructions; be sure to carefully follow the instructions before switching to a newer profile.

After viewing the available profiles for the architecture, users can select a different profile for the system:

root #eselect profile set 2

Note
The developer sub-profile is specifically for Gentoo Linux development and is not meant to be used by casual users.

Optional: Adding a binary package host

Since December 2023, Gentoo's Release Engineering team has offered an official binary package host (colloquially shorted to just "binhost") for use by the general community to retrieve and install binary packages (binpkgs).

Adding a binary package host allows Portage to install cryptographically signed, compiled packages. In many cases, adding a binary package host will greatly decrease the mean time to package installation and adds much benefit when running Gentoo on older, slower, or low power systems.

Repository configuration

The repository configuration for a binhost is found in Portage's /etc/portage/binrepos.conf/ directory, which functions similarly to the configuration mentioned in the Gentoo ebuild repository section.

When defining a binary host, there are two important aspects to consider:

1. The architecture and profile targets within the sync-uri value do matter and should align to the respective computer architecture ( in this case) and system profile selected in the Choosing the right profile section.
2. Selecting a fast, geographically close mirror will generally shorten retrieval time. Review the mirrorselect tool mentioned in the Optional: Selecting mirrors section or review the online list of mirrors where URL values can be discovered.
   
   

FILE /etc/portage/binrepos.conf/gentoobinhost.confCDN-based binary package host example

[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

Installing binary packages

Portage will compile packages from code source by default. It can be instructed to use binary packages in the following ways:

1. The --getbinpkg option can be passed when invoking the emerge command. This method of for binary package installation is useful to install only a particular binary package.
2. Changing the system's default via Portage's FEATURES variable, which is exposed through the /etc/portage/make.conf file. Applying this configuration change will cause Portage to query the binary package host for the package(s) to be requested and fall back to compiling locally when no results are found.

For example, to have Portage always install available binary packages:

FILE /etc/portage/make.confConfigure Portage to use binary packages by default

# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

Please also run getuto for Portage to set up the necessary keyring for verification:

root #getuto

Additional Portage features will be discussed in the the next chapter of the handbook.

Optional: Configuring the USE variable

USE is one of the most powerful variables Gentoo provides to its users. Several programs can be compiled with or without optional support for certain items. For instance, some programs can be compiled with support for GTK+ or with support for Qt. Others can be compiled with or without SSL support. Some programs can even be compiled with framebuffer support (svgalib) instead of X11 support (X-server).

Most distributions compile their packages with support for as much as possible, increasing the size of the programs and startup time, not to mention an enormous amount of dependencies. With Gentoo, users can define what options for which a package should be compiled. This is where USE comes into play.

In the USE variable users define keywords which are mapped onto compile-options. For instance, ssl will compile SSL support in the programs that support it. -X will remove X-server support (note the minus sign in front). gnome gtk -kde -qt5 will compile programs with GNOME (and GTK+) support, and not with KDE (and Qt) support, making the system fully tweaked for GNOME (if the architecture supports it).

The default USE settings are placed in the make.defaults files of the Gentoo profile used by the system. Gentoo uses a complex inheritance system for system profiles, which will not be covered in depth during the installation process. The easiest way to check the currently active USE settings is to run emerge --info and select the line that starts with USE:

root #emerge --info | grep ^USE

USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."

Note
The above example is truncated, the actual list of USE values is much, much larger.

A full description on the available USE flags can be found on the system in /profiles/use.desc.

root #less /profiles/use.desc

Inside the less command, scrolling can be done using the ↑ and ↓ keys, and exited by pressing q.

As an example we show a USE setting for a KDE-based system with DVD, ALSA, and CD recording support:

root #nano /etc/portage/make.conf

FILE /etc/portage/make.confEnabling flags for a KDE/Plasma-based system with DVD, ALSA, and CD recording support

USE="-gtk -gnome qt5 kde dvd alsa cdr"

When a USE value is defined in /etc/portage/make.conf it is added to the system's USE flag list. USE flags can be globally removed by adding a - minus sign in front of the value in the the list. For example, to disable support for X graphical environments, -X can be set:

FILE /etc/portage/make.confIgnoring default USE flags

USE="-X acl alsa"

Warning
Although possible, setting -* (which will disable all USE values except the ones specified in make.conf) is strongly discouraged and unwise. Ebuild developers choose certain default USE flag values in ebuilds in order to prevent conflicts, enhance security, and avoid errors, and other reasons. Disabling all USE flags will negate default behavior and may cause major issues.

CPU_FLAGS_*

Some architectures (including AMD64/X86, ARM, PPC) have a USE_EXPAND variable called CPU_FLAGS_<ARCH>, where <ARCH> is replaced with the relevant system architecture name.

Important
Do not be confused! AMD64 and X86 systems share some common architecture, so the proper variable name for AMD64 systems is CPU_FLAGS_X86.

This is used to configure the build to compile in specific assembly code or other intrinsics, usually hand-written or otherwise extra, and is not the same as asking the compiler to output optimized code for a certain CPU feature (e.g. -march=).

Users should set this variable in addition to configuring their COMMON_FLAGS as desired.

A few steps are needed to set this up:

root #emerge --ask --oneshot app-portage/cpuid2cpuflags

Inspect the output manually if curious:

root #cpuid2cpuflags

Then copy the output into package.use:

root #echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

VIDEO_CARDS

The VIDEO_CARDS USE_EXPAND variable should be configured appropriately depending on the available GPU(s). Setting VIDEO_CARDS is not required for a console only install.

Below is an example of a properly set VIDEO_CARDS variable. Substitute the name of the driver(s) to be used.

FILE /etc/portage/make.conf

VIDEO_CARDS="amdgpu radeonsi"

Details for various GPU(s) can be found at the AMDGPU, Intel, Nouveau (Open Source), or NVIDIA (Proprietary) articles.

Optional: CFLAGS and CXXFLAGS

Important
Globally setting compiler flags via make.conf should not be done haphazardly. Compile flags can adversely affect build times, performance, and stability.

The CFLAGS and CXXFLAGS variables define the optimization flags for GCC C and C++ compilers respectively. By default, portage enables the -O2 and -pipe flags.

The -pipe uses pipes instead of files when possible. This does not change the compilers output, but can reduce compile times, at the cost of increased memory usage.

Warning
On systems with low memory, gcc might get killed. In that case, do not use -pipe.

Optimization levels

The -O flag (that is a capital O, not a zero), specifies the compiler optimization profile. For GCC, the following options are available:

• -O0 - No optimizations, debugging output should not be affected, GCC's default.
• -Os - Optimize for binary size, like O2, except for options which increase the binary size.
• -O1 - Perform basic optimizations, trying not to greatly increase compile time.
• -O2 - Optimize even more, enabling most optimizations that do not involve a space-speed tradeoff, portage's default.
• -O3 - Optimize even more than O2. Warning: This optimization level may result in unexpected behavior.

See also
The Handbook cannot all possible optimization options. For more information, read the GNU Online Manual(s) or the gcc info page (info gcc). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.

Tip
Although the GCC optimization article has more information on how the various compilation options can affect a system, the Safe CFLAGS article may be a more practical place for beginners to start optimizing their systems.

Target specification

A first setting is the -march= or -mtune= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments). A commonly used value is native as that tells the compiler to select the target architecture of the current system (the one users are installing Gentoo on).

When the CFLAGS and CXXFLAGS variables are defined, combine the several optimization flags in one string. The default values contained in the stage file archive should be good enough. The following one is just an example:

CODE Example CFLAGS and CXXFLAGS variables

# Compiler flags to set for all languages
COMMON_FLAGS=""
# Use the same settings for both variables
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"

Optional: Configure the ACCEPT_LICENSE variable

Starting with Gentoo Linux Enhancement Proposal 23 (GLEP 23), a mechanism was created to allow system administrators the ability to "regulate the software they install with regards to licenses... Some want a system free of any software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting." With a motivation to have more granular control over the type of software running on a Gentoo system, the ACCEPT_LICENSE variable was born.

During the installation process, Portage considers the value(s) set within the ACCEPT_LICENSE variable to determine if the requested package(s) meet the sysadmin's determination of an acceptable license. Here in lies a problem: the Gentoo ebuild repository is filled with thousands of ebuilds which results in hundreds of distinct software licenses... Does this implicate sysadmin into individually approving each and every new software license? Thankfully no; GLEP 23 also outlines a solution to this problem, a concept called license groups.

For the convenience of system administration, legally-similar software licenses have been bundled together - each according to its like-kind. License group definitions are available for viewing and are managed by the Gentoo Licenses project. While an individual license is not, license groups are syntactically preceded with an @ symbol, enabling them to be easily distinguished in the ACCEPT_LICENSE variable.

Some common license groups include:

A list of software licenses grouped according to their kinds.

Name	Description
@GPL-COMPATIBLE	GPL compatible licenses approved by the Free Software Foundation
@FSF-APPROVED	Free software licenses approved by the FSF (includes @GPL-COMPATIBLE)
@OSI-APPROVED	Licenses approved by the Open Source Initiative
@MISC-FREE	Misc licenses that are probably free software, i.e. follow the Free Software Definition but are not approved by either FSF or OSI
@FREE-SOFTWARE	Combines @FSF-APPROVED, @OSI-APPROVED, and @MISC-FREE.
@FSF-APPROVED-OTHER	FSF-approved licenses for "free documentation" and "works of practical use besides software and documentation" (including fonts)
@MISC-FREE-DOCS	Misc licenses for free documents and other works (including fonts) that follow the free definition but are NOT listed in @FSF-APPROVED-OTHER.
@FREE-DOCUMENTS	Combines @FSF-APPROVED-OTHER and @MISC-FREE-DOCS.
@FREE	Metaset of all licenses with the freedom to use, share, modify and share modifications. Combines @FREE-SOFTWARE and @FREE-DOCUMENTS.
@BINARY-REDISTRIBUTABLE	Licenses that at least permit free redistribution of the software in binary form. Includes @FREE.
@EULA	License agreements that try to take away your rights. These are more restrictive than "all-rights-reserved" or require explicit approval

Currently set system wide acceptable license values can be viewed via:

user $portageq envvar ACCEPT_LICENSE

@FREE

As visible in the output, the default value is to only allow software which has been grouped into the @FREE category to be installed.

Specific licenses or licenses groups for a system can be defined in the following locations:

• System wide within the selected profile - this sets the default value.
• System wide within the /etc/portage/make.conf file. System administrators override the profile's default value within this file.
• Per-package within a /etc/portage/package.license file.
• Per-package within a /etc/portage/package.license/ directory of files.

The system wide license default in the profile is overridden within the /etc/portage/make.conf:

FILE /etc/portage/make.confAccept licenses with ACCEPT_LICENSE system wide

# Overrides the profile's ACCEPT_LICENSE default value
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"

Optionally system administrators can also define accepted licenses per-package as shown in the following directory of files example. Note that the package.license directory will need created if it does not already exist:

root #mkdir /etc/portage/package.license

Software license details for an individual Gentoo package are stored within the LICENSE variable of the associated ebuild. One package may have one or many software licenses, therefore it be necessary to specify multiple acceptable licenses for a single package.

FILE /etc/portage/package.license/kernelAccepting licenses on a per-package basis

app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode

Important
The LICENSE variable in an ebuild is only a guideline for Gentoo developers and users. It is not a legal statement, and there is no guarantee that it will reflect reality. It is recommended to not solely rely on a ebuild developer's interpretation of a software package's license; but check the package itself in depth, including all files that have been installed to the system.

Optional: Updating the @world set

Updating the system's @world set is optional and will be unlikely to perform functional changes unless one or more of the following optional steps have been performed:

1. A profile target different from the stage file has been selected.
2. Additional USE flags have been set for installed packages.

Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.

Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:

root #emerge --ask --verbose --update --deep --newuse @world

Removing obsolete packages

It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.

root #emerge --ask --pretend --depclean

If happy, then proceed with a real depclean:

root #emerge --ask --depclean

Tip
If a desktop environment profile target has been selected from a non-desktop stage file, the @world update process could greatly extend the amount of time necessary for the install process. Those in a time crunch can work by this 'rule of thumb': the shorter the profile name, the less specific the system's @world set. The less specific the @world set, the fewer packages the system will require. E.g.:

• Selecting default/linux/amd64/ will likely require fewer packages to be updated, whereas
• Selecting default/linux/amd64//desktop/gnome/systemd will likely require more packages to be installed since the profile target has a larger @system and @profile sets: dependencies supporting the GNOME desktop environment.