プロファイル (Portage)

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Profile (Portage) and the translation is 64% complete.
Other languages:
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

Portage のプロファイルは、USE フラグのデフォルトの状態を規定し、/etc/portage/make.conf 内で見られる変数のほとんどについてのデフォルト値を設定し、システムパッケージの集合を定義し、利用可能なパッケージバージョンを選択します。

プロファイルは、コアシステム機能を定義しているため、Gentoo システムにとっての中心的な役割を持っています。Gentoo が機能する仕組みに対して根本的な変更があるときには、新しいプロファイルが利用可能になります。プロファイルのリリースは数年単位の期間が空く場合があります。以前のプロファイル (17.1) はおよそ 6 年前でした。

プロファイルは、意図されたシステムの利用方法に応じて、インストール時に選択されます。

プロファイルは通常は必要なときに簡単に切り換えることができますが、プロファイルによっては単にプロファイルを切り換えるだけではなく、さらなる手順がある場合もあります。プロファイルバージョンを変更するときは、対応するニュース項目を読んで、従ってから行ってください (名前が異なるプロファイルへの切り換えは大丈夫です)。異なる ABI (例: pure LLVM または musl) を持つプロファイルへの切り換えは、再インストールなしでは不可能です。

プロファイルは ebuild リポジトリを基礎として定義されます; メインリポジトリにあるプロファイルは Gentoo 開発者によって保守されていますが、ユーザも自身のプロファイルを定義することができます。

eselect ツールの 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.

パッケージマネージャ仕様では、プロファイルが USE フラグを設定または設定解除する方法 (グローバルに、またはパッケージ単位で)、USE フラグの設定または設定解除を無条件で強制する方法 (アーキテクチャの stable ブランチに対してグローバルに、またはパッケージ単位で)、およびパッケージまたは特定のバージョンをマスクする方法が定義されています。

旧式化したプロファイルは自身のディレクトリ内に、アップグレード先となる新しいプロファイルを指定する deprecated ファイルを置き、これにより Portage を介して管理者に自動的に警告が表示されます。

/var/db/repos/gentoo/profiles/default/linux/amd64/23.0 はデフォルトの amd64 23.0 プロファイルです。親ディレクトリ内のファイルもまたプロファイルの一部です (そのため異なるサブプロファイルにも共有されます)。このためプロファイルはカスケードされると言われます。eselect profile はプロファイルを設定することができます。

新しいプロファイルが作成される理由はさまざまです: コアパッケージ (sys-apps/baselayout、sys-devel/gcc、または sys-libs/glibc など) の、以前のバージョンとは互換性の無い新しいバージョンのリリース、デフォルトの USE フラグまたは仮想パッケージマッピングの変更、あるいはシステム全体の設定の変更などがあり得ます。

プロファイルは以下のいずれかとして宣言されます:

  • stable
  • dev (開発中)
  • exp (実験的)

安定版 (stable)

これらは完全にテストされたプロファイルであり、ほとんどの場合すぐ動作することが期待されているため、ユーザが簡単に使えるような状態で提供されているはずです。Gentoo の CI は、安定版プロファイルが健全な依存関係グラフを持っているか確認します。

安定版プロファイルの例は:

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

すべての安定版プロファイルは、末尾の (stable) によって示されています。

開発中 (dev)

プロファイルが「安定版」としてマークされる前は、プロファイルは開発中の段階にあります。現在開発中のプロファイル (dev) としてマークされます。Gentoo の CI はこれらのプロファイルについて依存関係グラフの問題を確認しますが、 エラーではなく警告のみを発します。

これらのプロファイルは、それを使用することでしか解決できない特定の要求がある場合にのみ、実行されるべきです。

すべての開発者プロファイルは、末尾の (dev) によって明確に示されています。

実験的 (exp)

実験的プロファイルは、その名が示す通り、実験です。新しい「永続的な」プロファイルになるかもしれませんし、ならないかもしれません。加えて、あまり使われないアーキテクチャでは、多くのプロファイルが実験的としてマークされているのに気付かれるかもしれません。

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.

端的に言えば、これらのプロファイルを実行すると問題に遭遇するかもしれないので、出し抜けに問題を抱えることを想定しておいてください。

実験的プロファイルの例は:

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

すべての実験的プロファイルは、末尾の (exp) によって明確に示されています。

デフォルトで有効化されているフラグを確認するには、以下のコマンドを使用してください:

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"

プロファイルを切り換える

プロファイルの変更について

警告
基本的なプロファイルの変更の多くは単純に行えますが、特定のプロファイルの間の変更は、複数の手順からなる作業になる場合があります。これらのための手続きに正しく従うことができないと問題が発生する場合があるので、ユーザは確実に適切なドキュメンテーションを読み、理解し、従うようにするべきです。
メモ
異なる ABI (例: pure LLVM または musl) を持つプロファイルへの切り換えは、再インストールなしでは不可能です。

システムの使い方が変わったとき、新しいプロファイルがリリースされたとき、あるいは別のプロファイルのほうがより適していると気付いたときには、プロファイルを切り換える必要があるかもしれません。

プロファイルの変更は単純な場合もありますが、非自明でない場合もあります:

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.

重要
プロファイルの変更を行う前には、Gentoo ebuild リポジトリが同期され、システムが更新されていることを確認してください。
ヒント
通常通り、特にシステム全体への変更の前には、システムは定期的にバックアップを行うべきです。

一般的なプロファイル切り換え手順

重要
以下の手順は、特定のプロファイル変更に応じて調整してください - これらの手順に盲目に従うことはやめてください: ここで提供されるのはプロファイル変更の一般的な概要であり、すべてのプロファイル変更に適応できる決定的な方法ではありません。各コマンドの出力に注意を払い、必要な追加の手順があればそれに従ってください。前の節と、この記事の先頭の内容を忘れずに読んでおいてください。プロファイルの切り換えの前に、適切なニュース項目や、それ以外の関連するドキュメンテーションを読んでください。

各プロファイルは異なる特性を持っている場合もありますが、一般的な手順は以下の通りです。まず、システムを更新してください ( depclean の手順が必要なパッケージを削除しようとしていないことを確認してください):

root #emaint --auto sync
root #emerge --ask --verbose --update --deep --newuse @world
root #emerge --ask --depclean

利用可能なプロファイルを一覧表示して、適切な切り換え先のプロファイルを選んでください:

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

新しいプロファイルを設定してください:

root #eselect profile set 2

ツールチェーンの変更

TODO: LLVM ツールチェーンの更新

新しいプロファイルに大きな変更 (17.1 から 23.0 プロファイルへの更新のように) がある場合、または新しいツールチェーン (通常のプロファイルから hardened、あるいはその逆など) が必要になる場合は、ツールチェーン全体を更新し、既存のバイナリパッケージを削除することを検討してください:

root #rm -r /var/cache/binpkgs/*

そして、/etc/portage/binrepos.conf/ のファイルの行を何らかの方法で修正/削除/コメントアウトしてください。

binutils を更新します:

root #emerge --ask --verbose --oneshot binutils

新しい binutils が使用されているか確認します:

root #binutils-config -l

正しくない binutils が設定されている場合、設定して環境を更新します:

root #binutils-config #put_number_from_the_previous_list#
root #env-update && source /etc/profile

GCC を更新します:

root #emerge --ask --verbose --oneshot sys-devel/gcc

新しい gcc が使用されているか確認します:

root #gcc-config -l

正しくない gcc が設定されている場合、設定して環境を更新します:

root #gcc-config #put_number_from_the_previous_list#
root #env-update && source /etc/profile

libc (glibc または musl) を更新します:

root #emerge --ask --verbose --oneshot sys-libs/glibc
root #emerge --ask --verbose --oneshot sys-libs/musl

念のため、もう一度環境を更新します:

root #env-update && source /etc/profile

libtool を再 emerge します:

root #emerge --ask --oneshot libtool

安全のために、${PKGDIR} のバイナリパッケージキャッシュの内容を再度削除します:

root # rm -r /var/cache/binpkgs/*

最後にシステムを更新する

ツールチェーンを更新する必要がある場合は、--emptytree オプションを emerge に追加して、新しいツールチェーンを使ってすべてのパッケージを再ビルドしてください:

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

ツールチェーンを更新する必要が無い場合は、単純にシステムへの変更を適用してください:

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

不要なパッケージを削除してください。まず出力を確認し、重要なパッケージが削除対象として列挙されていないか確認するのを忘れないでください:

root #emerge --ask --depclean

新しいプロファイルに移行する (プロファイルの更新、またはアップグレード)

警告
プロファイルのアップグレードは軽々しく扱われるものではありません。適切な指示を読み、それに確実に従うようにしてください。

ユーザには、Gentoo ebuild リポジトリの同期後に報告されるニュース項目の公開によって、プロファイルの更新が利用可能になったことが通知されます。このニュース項目には、適切に従うべき、詳細な手順が含まれます。プロファイルアップグレードは自明な操作ではなく、通常通り、システムは定期的にバックアップされるべきです - 特にシステム全体への変更の前には。

プロファイル更新に関する情報については、Gentoo のアップグレードについての記事を参照してください。

開発者とパワーユーザ向けのプロファイル

プロファイルの構造

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 Package Manager Specification. A summary is also contained in the Devmanual and man portage.

プロファイルを組み合わせる

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 specification 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 Package Manager Specification.

カスタムプロファイルを作成する

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:

ファイル /etc/portage/repos.conf/local.conf
[local]
# 'eselect repository' default location
location = /var/db/repos/local
ファイル /var/db/repos/local/profiles/repo_name
local
ファイル /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 ; THIS LINE DOES NOT APPEAR IF create overlay with `eselect repository create local`, so you can add it in the case by your own.
user $ls -ld /var/db/repos/local
drwxr-xr-x 4 user user 4096 Dec 15 11:50 /var/db/repos/local
重要
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 Package Manager Specification!

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:

ヒント
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!
ファイル /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:

ファイル /var/db/repos/local/profiles/32bit/package.use
dev-libs/test-package abi_x86_32 -extras
ファイル /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:
ファイル /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.

ファイル 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)
ファイル /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.

関連項目

外部資料

Retrieved from "https://wiki.gentoo.org/index.php?title=Profile_(Portage)/ja&oldid=1406102"