Profile (Portage)

This page contains changes which are not marked for translation.

Portage - the heart of Gentoo
emerge — configuration — ebuild repository — dispatch-conf

world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles

Resources

Home

GitWeb

A Portage profile specifies the default state of USE flags, sets default values for most variables found in /etc/portage/make.conf, defines a set of system packages, and selects available package versions.

Profiles are central to a Gentoo system because they define core system functionality. New profiles are made available when there are fundamental changes to the way Gentoo works. Profile releases can be years apart, the previous (17.1) profile was nearly 6 years old.

A profile is selected at install time, according to the intended use of the system.

Profiles can usually be switched easily when required, though for some profile changes there are more steps than just switching the profile. Only change profile versions (different names are fine) after reading and following the corresponding news item. It is not possible to change to profiles with a different ABI (e.g. pure LLVM or musl) without a reinstall.

Profiles are defined on an ebuild repository basis; the ones from the main repository are maintained by the Gentoo developers, but users can define their own.

The profile module of the eselect tool allows users to switch profiles.

See also
See the Handbook has information on selecting profiles.

What is a profile

/var/db/repos/gentoo/profiles store profile subdirectory configuration files. The symbolic link /etc/portage/make.profile describes the current profile's running architecture, default USE flags, and @system package ebuilds.

The Package Manager Specification (PMS) defines how profiles set or unset USE flags (globally or per package); unconditionally force set or unset USE flags (globally for the architecture's stable branch or per package); and mask packages or specified versions.

Obsoleted profiles place a deprecated file in their directory naming the new profile to upgrade to, automatically warning administrators through Portage.

/var/db/repos/gentoo/profiles/default/linux/amd64/23.0 is the default amd64 23.0 profile. The files in the parent directories are part of the profile as well (and are therefore shared by different subprofiles). This is why profiles are said to be cascaded. Eselect profile may set the profile.

There are various reasons that a new profile may be created: the release of new versions of core packages (such as sys-apps/baselayout, sys-devel/gcc, or sys-libs/glibc) that are incompatible with previous versions, a change in the default USE flags or in the virtual mappings, or maybe a change in system-wide settings.

Profiles are stated as:

stable
dev (in-development)
exp (experimental)

Stable (stable)

These are fully tested profiles and should provide the user with the easiest time as they are expected to mostly just work. Gentoo's CI checks that stable profiles have a sound dependency graph.

An example of stable profiles are:

default/linux/amd64/23.0
default/linux/amd64/23.0/systemd
default/linux/amd64/23.0/desktop

All stable profiles are marked with (stable) at the end of them.

In-Development (dev)

Before a profile is marked as 'stable', they are being developed. Profiles which are currently in development are marked as (dev). Gentoo's CI checks those profiles for issues in the dependency graph, but issues only a warning and not an error.

Users running these should only be doing so if they have a certain need that can only be resolved by using them.

All developer profiles are clearly marked with (dev) at the end of them.

Experimental (exp)

An experimental profile is, as the name suggests, an experiment. It may or may not result in a new "permanent" profile. Besides that, you will find that many profiles of exotic architectures are marked as experimental.

Experimental should work as they have undergone a certain level of testing. However, the fixes to make it run are normally included in testing keyword packages so a user of these should either be running ~ARCH globally or at the very least be prepared to use /etc/portage/package.accept_keywords to pull in the latest versions and fill a bug to stable request the package if found to be safe by the user. In short, you may run into issues running these profiles so expect to have random issues. An example of experimental profiles are:

default/linux/amd64/23.0/musl/llvm
default/linux/amd64/23.0/musl/hardened

All experimental profiles are clearly marked with (exp) at the end of them.

To check flags enabled by default use command:

user $USE_ORDER="defaults:pkginternal:repo" emerge --info|grep USE

USE="X a52 aac acl acpi activities alsa amd64 bluetooth branding bzip2 cairo cdda cdr cet crypt cups dbus declarative dri dts dvd dvdr elogind encode exif flac gdbm gif gpm gtk gui iconv icu ipv6 jpeg kde kf6compat kwallet lcms libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses networkmanager nls ogg opengl openmp pam pango pcre pdf pipewire plasma png policykit ppds pulseaudio qml qt5 qt6 readline screencast sdl seccomp semantic-desktop sound spell ssl startup-notification svg test-rust tiff truetype udev udisks unicode upower usb vorbis vulkan wayland widgets wxwidgets x264 xattr xcb xft xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gcc_12" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isyncitrax navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" GUILE_SINGLE_TARGET="3-0" GUILE_TARGETS="3-0" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-2" POSTGRES_TARGETS="postgres16" PYTHON_SINGLE_TARGET="python3_12" PYTHON_TARGETS="python3_12" RUBY_TARGETS="ruby32" VIDEO_CARDS="amdgpu dummy fbdev intel nouveau radeon radeonsi vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account"

Switching between profiles

About profile changes

Warning
Though many basic profile changes are simple, changing between certain profiles can be a multi-step process. Failing to correctly follow procedures for these could lead to issues, so users should be sure to read, understand, and follow the appropriate documentation.

Note
It is not possible to change to profiles with a different ABI (e.g. pure LLVM or musl) without a reinstall.

Sometimes when the usage of a system changes, a new profile is released, or when realizing that another profile is a better fit, it can be necessary to switch profiles.

Some profile changes are simple, but others can be non-trivial:

Changing to or from Hardened or SELinux profiles, for example, requires specific steps, as described in the relevant documentation.
Changing to or from OpenRC or systemd profiles, is another case for which it is important to follow the appropriate documentation.

If a profile is to be changed to a more recent version, for example after the release of a new profile (a "profile update"), see the next section for information on updating profiles.

Important
Make sure the Gentoo ebuild repository has been synced, and the system updated before performing any profile changes.

Tip
As always, systems should be regularly backed up, particularly before system changes.

General profile-switch procedure

Important
Adapt the following instructions to the specific profile change - do not blindly follow these steps: they give the general outline of a profile change, not a definitive method for all profile changes. Pay attention to the output of each command, and follow any necessary extra steps. Be sure to read the previous section and the paragraphs at the top of this article. Read any appropriate news items, and all other relevant documentation before switching profiles.

Though each profile change may have specificities, the general procedure is as follows. First update the system (make sure the depclean step is not trying to remove required packages):

root #emaint --auto sync

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

root #emerge --ask --depclean

List available profiles, then choose the appropriate profile to switch to:

root #eselect profile list

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

Set the new profile:

root #eselect profile set 2

Apply changes to the system:

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

Remove unneeded packages, be sure to check the output first that no important packages are listed to be removed:

root #emerge --ask --depclean

Migrating to a new profile (updating, or upgrading profiles)

Warning
Profile upgrades are not to be taken lightly. Make sure to read and follow proper instructions.

The user is informed of the availability of a profile update by the publication of a news item, which will be reported after a Gentoo ebuild repository sync. This will include detailed instructions that should be properly followed. A profile upgrade is a non trivial operation and, as always, systems should be regularly backed up - particularly before system changes.

See the article on upgrading Gentoo for information on profile updates.

Profiles for developers and power users

Profile structure

Profiles are defined in directories contained in the profiles subdirectory of an ebuild repository, which also contains the mandatory repo_name file that specifies the name of the ebuild repository. These are some of the files that can be present in a directory that defines a profile:

eapi, which specifies the EAPI to use when handling the directory in question.
packages, which specifies packages that are members of the system or profile set.
package.mask, which specifies masked packages. The administrator can unmask a package masked by the profile using /etc/portage/package.unmask.
make.defaults, with make.conf-like variable assignments, including USE flag global default state (set or unset) and profile variables with special meaning (like ARCH, USE_EXPAND, CONFIG_PROTECT, IUSE_IMPLICIT, etc.). Administrator settings in /etc/portage/make.conf and /etc/portage/package.use override profile settings in make.defaults.
package.use, which defines default USE flag state on a per package basis. Administrator settings in /etc/portage/make.conf and /etc/portage/package.use override profile settings in package.use.
use.force and use.mask, which unconditionally set or unset USE flags, overriding administrator settings in /etc/portage/make.conf and /etc/portage/package.use. If a flag is both masked and forced, the mask takes precedence.
package.use.force and package.use.mask, which unconditionally set or unset USE flags on a per package basis, overriding administrator settings in /etc/portage/make.conf and /etc/portage/package.use, and profile settings in use.force and use.mask.
use.stable.force, use.stable.mask, package.use.stable.force and package.use.stable.mask, which work like use.force, use.mask, package.use.force and package.use.mask, but override them for packages in the stable branch of the current architecture.

USE flag settings in profile use.* and package.use.* files can be overridden by the administrator with files of the same name in directory /etc/portage/profile. For complete information about profile directory structure please consult the PMS. A summary is also contained in the Devmanual and man portage.

Combining profiles

Profile settings can be combined in a cascading/stacking fashion, by including a file named parent in the directory that defines the profile. This makes the profile inherit settings from other profiles, which can be partially overriden. For example, by unsetting a USE flag by default that is set by default in a parent profile and vice-versa, unforcing or inverting its forced state, unmasking packages masked in a parent profile, adding or removing additional packages to/from the system set, etc. parent must contain a list of profile pathnames, relative to the directory that contains the file. As an extension, with portage-2 added to the profile-format key in metadata/layout.conf, Portage also allows prepending an installed ebuild repository name (as specified in /etc/portage/repos.conf) followed by a colon (':') to a profile pathname, which is then interpreted relative to the profiles subdirectory of the named ebuild repository.

Because parent profiles can also contain a parent file, an inheritance tree is produced as a result. The Package Manager Specification specifies how settings in each file of a profile directory (i.e. packages, make.defaults, package.use.force and package.use.mask, etc.) combine. In particular, it defines an ordering of parent profiles to determine the final settings: the inheritance tree is traversed depth-first, left-to-right, with multiple occurrences of the same profile processed repeatedly. The left-to-right order is defined by line order in parent files.

The PMS uniformly calls 'profile' all directories with suitable structure that are contained in an ebuild repository's profiles subdirectory. A subset designated as 'valid for use' must be listed in file profiles/profiles.desc, a text file that must contain lines with three fields separated by whitespace characters (space and TAB):

The first one is an architecture, in the format valid as the value of ARCH (and for setting KEYWORDS in ebuilds), e.g. amd64, arm, ppc64, etc. These are listed in the main repository's profiles/arch.list file.
The second one is a profile path name, relative to the profiles directory.
The third and last one is a 'stability indicator'. The Gentoo ebuild repository, for instance, uses stable, dev and exp (experimental) for that field.

The eselect profile list command only shows profiles in profiles.desc files of all repositories configured in /etc/portage/repos.conf, with an architecture field that matches the machine's architecture. These are the ones that in most contexts are referred to as 'profiles' with no further qualification. Profiles not named in profiles.desc might be named in other profiles' parent files, and can be thought of as 'subprofiles' or 'profile building blocks'.

Following is an example that shows parent profiles and the inheritance tree for profile default/linux/amd64/23.0/desktop/gnome/systemd from the Gentoo ebuild repository. Profiles pathnames relative to the profiles subdirectory are shown so that the filesystem layout can be inferred, top-to-bottom ordering respects line ordering in relevant parent files.

default/linux/amd64/23.0/desktop/gnome/systemd  17 
 | L 
 +--> default/linux/amd64/23.0/desktop/gnome  15 
 |     | L 
 |     +--> default/linux/amd64/23.0/desktop  12 
 |     |     | L 
 |     |     +--> default/linux/amd64/23.0  10 
 |     |     |     | L 
 |     |     |     +--> default/linux/amd64  3 
 |     |     |     |     | L 
 |     |     |     |     +--> base  1 
 |     |     |     |     | R 
 |     |     |     |     +--> default/linux  2 
 |     |     |     |
 |     |     |     +--> arch/amd64/lib32  7 
 |     |     |     |     |
 |     |     |     |     +--> arch/amd64  6 
 |     |     |     |           | L 
 |     |     |     |           +--> arch/base  4 
 |     |     |     |           | R 
 |     |     |     |           +--> features/multilib  5 
 |     |     |     | R 
 |     |     |     +--> releases/23.0  9 
 |     |     |           |
 |     |     |           +--> releases  8 
 |     |     | R 
 |     |     +--> targets/desktop  11 
 |     | R 
 |     +--> targets/desktop/gnome  14 
 |           |
 |           +--> targets/desktop  13 
 | R 
 +--> targets/systemd  16

The L and R markers indicate the leftmost and rightmost branches in the corresponding tree representation, and the numbers represent the order in which profiles are considered for computing the final settings. Profiles with larger numbers override settings in profiles with smaller numbers. The following table gives a quick overview of notable settings for each of the intervening profiles, as well as the relevant files that implement them:

Profile	Notable settings	Relevant file(s)
base	Define most USE_EXPAND and profile variables, define 'base' system set packages, set `KERNEL`, `ELIBC`, and `USERLAND` to `linux`, `glibc`, and `GNU`, respectively.	make.defaults, packages, use.force
default/linux	Add packages considered essential for Linux to the system set, set USE flags, set default value of `LDFLAGS`, unmask Linux-specific USE flags	make.defaults, packages, use.mask, package.use.mask
default/linux/amd64	Add profiles base and default/linux to the inheritance tree	parent
arch/base	Define the `ARCH` USE_EXPAND variable, mask USE flags only supported for some architectures	make.defaults, use.mask, package.use.mask
arch/amd64	Set `ARCH` to `amd64`, set `CHOST`, `ABI`, `MULTILIB_ABIS` and `DEFAULT_ABI` appropriately, set default values of `ACCEPT_KEYWORDS`, `CFLAGS`, `CXXFLAGS`, `FFLAGS`, and `FCFLAGS`, define the `CPU_FLAGS_X86` USE_EXPAND variable, unmask USE flags supported for amd64	make.defaults, use.mask, package.use.mask
features/multilib	Unmask and unconditinally set the `multilib` USE flag	all
arch/amd64/lib32	Set `LIBDIR_x86` to `lib32`, and `SYMLINK_LIB` to `yes` to make {usr,}/lib a symlink to {usr,}/lib64	make.defaults
default/linux/amd64/23.0	Add profiles arch/amd64/lib32 and releases/23.0 to the inheritance tree	parent
releases	Set USE flags	make.defaults
releases/23.0		package.mask, package.use.force
default/linux/amd64/23.0/desktop	Add profile targets/desktop to the inheritance tree	parent
targets/desktop	Set USE flags	make.defaults, package.use, package.use.force
default/linux/amd64/23.0/desktop/gnome	Add profile targets/desktop/gnome to the inheritance tree	parent
targets/desktop/gnome	Set USE flags; in particular, globally set `gnome`	make.defaults, package.use
default/linux/amd64/23.0/desktop/gnome/systemd	Add profile targets/systemd to the inheritance tree	parent
targets/systemd	Globally set `systemd` and `udev` USE flags, mask sys-fs/udev and eudev	make.defaults, package.mask, package.use.force

For information about the exact way in which settings in the different profile files combine please consult the PMS.

Creating custom profiles

Users can create specialized, custom profiles not available in the Gentoo ebuild repository, and put them in an ebuild repository. They can refer to profiles from the Gentoo ebuild repository in their parent file using the 'gentoo:' prefix, to avoid recreating all profile definitions, provided that the profile-formats key in metadata/layout.conf of the ebuild repository contains portage-2, as shown below.

Following are examples of a custom profile created locally in an ebuild repository named 'local'. The ebuild repository is assumed to be in /var/db/repos/local (i.e. the default location for eselect repository), world-readable and owned by a non-root user. It is also assumed to contain a package dev-libs/test-package that installs libraries:

FILE /etc/portage/repos.conf/local.conf

[local]
# 'eselect repository' default location
location = /var/db/repos/local

FILE /var/db/repos/local/profiles/repo_name

local

FILE /var/db/repos/local/metadata/layout.conf

# Slave repository rather than stand-alone
masters = gentoo
profile-formats = portage-2 # This line will be important, ensure It's there

user $ls -ld /var/db/repos/local

drwxr-xr-x 4 user user 4096 Dec 15 11:50 /var/db/repos/local

Important
Since the profile inheritance tree is traversed depth-first, left-to-right, the order in which profile pathnames are listed in parent files can dramatically affect the resulting settings, as left-to-right ordering is defined by it. If emerge yields resolution problems after switching to the custom profile, try changing the order of the lines. It may be impossible to get some combinations to work correctly; make sure to have read and understood the algorithm specified in the PMS!

Example 1: Combining multiple profiles from the Gentoo ebuild repository

A profile named hardened-desktop will be created, which inherits settings from default/linux/amd64/23.0/hardened and targets/desktop in the main Gentoo ebuild repository.

First, create the hardened-desktop directory in the ebuild repository's profiles subdirectory:

user $cd /var/db/repos/local/profiles

user $mkdir hardened-desktop && echo 8 >hardened-desktop/eapi

Then, create the parent file:

Tip
You can view available profiles to combine by viewing the directory tree at `/var/db/repos/gentoo/profiles/`. You can also combine other profiles from other repos the same way!

FILE /var/db/repos/local/profiles/hardened-desktop/parent

gentoo:default/linux/amd64/23.0/hardened
gentoo:targets/desktop

Finally, insert the newly created profile in the ebuild repository's profiles.desc file, giving it a dev 'stability indicator' for example:

user $echo `portageq envvar ARCH` hardened-desktop dev >> /var/db/repos/local/profiles/profiles.desc

Verify that eselect profile list lists the new profile:

user $eselect profile list

Available profile symlink targets:
  ...
  [99]  local:hardened-desktop (dev)

Example 2: Adding custom USE flags by profile

user $equery uses test-package

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset
 * Found these USE flags for dev-libs/test-package-1
 U I
 - - abi_x86_32 : 32-bit (x86) libraries
 - - extras     : Builds the libprofile-test-extra library

A profile named custom will be created, which inherits settings from default/linux/amd64/23.0 in the Gentoo ebuild repository, and two local profiles: 32bit, which sets the abi_x86_32 USE flag and unsets the extras USE flag by default for the package, and with-extras, which does exactly the opposite, to illustrate final settings determination.

First, create the 32bit and with-extras directories in the ebuild repository's profiles subdirectory:

user $cd /var/db/repos/local/profiles

user $mkdir 32bit with-extras && echo 8 >with-extras/eapi && && echo 8 >32bit/eapi

Then create a package.use to change use flags of dev-libs/test-package:

FILE /var/db/repos/local/profiles/32bit/package.use

dev-libs/test-package abi_x86_32 -extras

FILE /var/db/repos/local/profiles/with-extras/package.use

dev-libs/test-package -abi_x86_32 extras

Then, create the custom directory:

user $mkdir custom && echo 8 >custom/eapi

And add the parent file:

FILE /var/db/repos/local/profiles/profile-name/parent

gentoo:default/linux/amd64/23.0
../with-extras
../32bit

Finally, insert the newly created profile in the ebuild repository's profiles.desc file, giving it a dev 'stability indicator' for example:

user $echo `portageq envvar ARCH` $profile_name dev >>profiles.desc

Verify that eselect profile list lists the new profile:

user $eselect profile list

Available profile symlink targets:
  ...
  [46]  local:custom (dev)

Now it is possible to actually switch to the new profile using eselect profile set:

root #eselect profile set 46

Check the result:

user $eselect profile show

Current /etc/portage/make.profile symlink:
  local:custom

user $ls -l /etc/portage/make.profile

lrwxrwxrwx 1 root root 40 Dec 15 12:00 /etc/portage/make.profile -> ../../var/db/repos/local/profiles/custom

This shows that eselect profile set updated the /etc/portage/make.profile symbolic link. In the general case, it would be necessary to run a world rebuild to apply the new settings to all packages, but checking first to make sure that the desired changes are going into effect with --ask:

root #emerge --ask --update --newuse --deep --complete-graph @world

However, for this example, knowing that the profile settings only affect dev-libs/test-package and assuming that the previously chosen profile was default/linux/amd64/23.0, only that package's reinstallation will be done.

user $equery uses test-package

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset
 * Found these USE flags for dev-libs/test-package-1:
 U I
 + - abi_x86_32 : 32-bit (x86) libraries
 - - extras     : Builds the libprofile-test-extra library

This shows that because profile 32bit comes last in file custom/parent, its setting override those in profile with-extras, and the 32-bit version of the package's libraries is built.

FILE test-package-1/MakefilePackage's makefile snippet

%.so: %.c
   @echo Building $@ for architecture $$ARCH and ABI $$ABI "(CHOST=$$CHOST)"
   $(CC) -shared -fPIC -Wl,-soname=$@.1 $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LDLIBS)

FILE /var/db/repos/local/dev-libs/test-package/test-package-1.ebuildEbuild snippet

EAPI=8

inherit toolchain-funcs multilib-build multilib-minimal

# ...

IUSE="extras" # abi_x86_32 comes from an eclass

# ...

multilib_src_compile() {
   tc-export CC
   emake extras=$(usex extras)
}

root #ACCEPT_KEYWORDS="~amd64" emerge --oneshot test-package

Calculating dependencies  ... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-libs/test-package-1::local
 * test-package-1.tar.gz BLAKE2B SHA512 size ;-) ...                     [ ok ]
>>> Unpacking source...
>>> Unpacking test-package-1.tar.gz to /var/tmp/portage/dev-libs/test-package-1/work
>>> Source unpacked in /var/tmp/portage/dev-libs/test-package-1/work
>>> Preparing source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * Will copy sources from /var/tmp/portage/dev-libs/test-package-1/work/test-package-1
 * abi_x86_32.x86: copying to /var/tmp/portage/dev-libs/test-package-1/work/test-package-1-abi_x86_32.x86
 * abi_x86_64.amd64: copying to /var/tmp/portage/dev-libs/test-package-1/work/test-package-1-abi_x86_64.amd64
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * abi_x86_32.x86: running multilib-minimal_abi_src_configure
 * abi_x86_64.amd64: running multilib-minimal_abi_src_configure
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * abi_x86_32.x86: running multilib-minimal_abi_src_compile
make extras=no

Building libprofile-test.so for architecture amd64 and ABI x86 (CHOST=i686-pc-linux-gnu)

x86_64-pc-linux-gnu-gcc -m32 -shared -fPIC -Wl,-soname=libprofile-test.so.1  -O2 -pipe -Wl,-O1 -Wl,--as-needed -o libprofile-test.so libprofile-test.c
 * abi_x86_64.amd64: running multilib-minimal_abi_src_compile
make extras=no

Building libprofile-test.so for architecture amd64 and ABI amd64 (CHOST=x86_64-pc-linux-gnu)

x86_64-pc-linux-gnu-gcc -shared -fPIC -Wl,-soname=libprofile-test.so.1  -O2 -pipe -Wl,-O1 -Wl,--as-needed -o libprofile-test.so libprofile-test.c
>>> Source compiled.
>>> Test phase [not enabled]: dev-libs/test-package-1

>>> Install test-package-1 into /var/tmp/portage/dev-libs/test-package-1/image/ category dev-libs
 * abi_x86_32.x86: running multilib-minimal_abi_src_install
make DESTDIR=/var/tmp/portage/dev-libs/test-package-1/image/ libdir=/usr/lib32 extras=no install

Installing: libprofile-test.so

 * abi_x86_64.amd64: running multilib-minimal_abi_src_install
make DESTDIR=/var/tmp/portage/dev-libs/test-package-1/image/ libdir=/usr/lib64 extras=no install

Installing: libprofile-test.so

>>> Completed installing test-package-1 into /var/tmp/portage/dev-libs/test-package-1/image/

 * Final size of build directory: 68 KiB
 * Final size of installed tree:  32 KiB

strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   usr/lib32/libprofile-test.so.1
   usr/lib64/libprofile-test.so.1

>>> Installing (1 of 1) dev-libs/test-package-1::local
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

Messages printed by the package's makefile (informational ones highlighted) show variables ARCH, CHOST_x86, CFLAGS_x86 (which adds GCC's -m32 option for 32-bit builds) and LDFLAGS, set by profile default/linux/amd64/23.0, are being inherited and are available in the ebuild's environment.

Now to see what happens if line order is changed in custom/parent:

user $cat <<EOF >$profile_name/parent

> gentoo:default/linux/amd64/23.0
> ../32bit
> ../with-extras
> EOF

user $equery uses test-package

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset
* Found these USE flags for dev-libs/test-package-1:
 U I
 - + abi_x86_32 : 32-bit (x86) libraries
 + - extras     : Builds the libprofile-test-extra library

This shows that because it now comes last in file custom/parent, settings in profile with-extras override those in profile 32bit, and, on a reinstallation, the 32-bit version of the package's libraries would be removed, and library libprofile-test-extra would be built:

root #ACCEPT_KEYWORDS="~amd64" emerge --oneshot test-package

Calculating dependencies  ... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-libs/test-package-1::local
 * test-package-1.tar.gz BLAKE2B SHA512 size ;-) ...                     [ ok ]
>>> Unpacking source...
>>> Unpacking test-package-1.tar.gz to /var/tmp/portage/dev-libs/test-package-1/work
>>> Source unpacked in /var/tmp/portage/dev-libs/test-package-1/work
>>> Preparing source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * Will copy sources from /var/tmp/portage/dev-libs/test-package-1/work/test-package-1
 * abi_x86_64.amd64: copying to /var/tmp/portage/dev-libs/test-package-1/work/test-package-1-abi_x86_64.amd64
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * abi_x86_64.amd64: running multilib-minimal_abi_src_configure
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/test-package-1/work/test-package-1 ...
 * abi_x86_64.amd64: running multilib-minimal_abi_src_compile
make extras=yes

Building libprofile-test.so for architecture amd64 and ABI amd64 (CHOST=x86_64-pc-linux-gnu)

x86_64-pc-linux-gnu-gcc -shared -fPIC -Wl,-soname=libprofile-test.so.1  -O2 -pipe -Wl,-O1 -Wl,--as-needed -o libprofile-test.so libprofile-test.c

Building libprofile-test-extra.so for architecture amd64 and ABI amd64 (CHOST=x86_64-pc-linux-gnu)

x86_64-pc-linux-gnu-gcc -shared -fPIC -Wl,-soname=libprofile-test-extra.so.1  -O2 -pipe -Wl,-O1 -Wl,--as-needed -o libprofile-test-extra.so libprofile-test-extra.c
>>> Source compiled.
>>> Test phase [not enabled]: dev-libs/test-package-1

>>> Install test-package-1 into /var/tmp/portage/dev-libs/test-package-1/image/ category dev-libs
 * abi_x86_64.amd64: running multilib-minimal_abi_src_install
make DESTDIR=/var/tmp/portage/dev-libs/test-package-1/image/ libdir=/usr/lib64 extras=yes install

Installing: libprofile-test.so libprofile-test-extra.so

>>> Completed installing test-package-1 into /var/tmp/portage/dev-libs/test-package-1/image/

 * Final size of build directory: 52 KiB
 * Final size of installed tree:  28 KiB

strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version
   usr/lib64/libprofile-test.so.1
   usr/lib64/libprofile-test-extra.so.1

>>> Installing (1 of 1) dev-libs/test-package-1::local
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

External resources

profiles: Finally deprecate amd64 17.0 profiles
Bug 506276 — (no-symlink-lib) - kill SYMLINK_LIB=yes support.