Gentoo Linux mips 手册：使用Portage

Portage文件

配置指南

Portage附带了一个默认的配置文件/usr/share/portage/config/make.globals。当你打开它时，你就会发现所有的Portage配置选项都是通过变量来控制的。Portage读取的是什么变量，这些变量分别又是什么意思，下面将详细解释。

因为许多配置命令在不同的架构下是不同的，Portage 也有相应的各组默认配置文件，它们是你的profile的一部分。你的 profile 是/etc/portage/make.profile 这个链接文件指向的目录；Portage 的配置选项是在你的make.defaults以及所有被继承的profile中的make.defaults 文件中设定的。我们稍后将详细解释profile及/etc/portage/make.profile目录。

如果打算改变配置变量，不要变更/usr/share/portage/config/make.globals 或者make.defaults。而应该修改/etc/portage/make.conf，它比前面的几个文件有更高的优先级。你会发现还有一个/usr/share/portage/config/make.conf.example文件。顾名思义，它仅仅是一个例子而已——Portage并不读取这个文件。

你也可以将一个Portage的配置变量定义为环境变量，但我们并不推荐这样做。

Profile特定的信息

我们已经见到过 /etc/portage/make.profile 目录了。不过，这并不是一个真正的目录，而是一个指向 /var/db/repos/gentoo/profiles/ 的符号链接，默认情况下是一个位于/usr/portage/profiles里的目录，虽然你也可以在其他地方创建自己的profile并指向他们。这个符号链接指向的profile就是你的系统所使用的。

一个profile包含了Portage需要的与架构相关的信息，比如该profile对应的system包含的软件包的列表，以及对这个profile来说不能运行的（或者被屏蔽掉）的软件列表，等等。

用户特定的配置

当你需要变更Portage安装软件的行为时，你需要做的就是编辑 /etc/portage/ 中的文件。我们强烈建议你使用/etc/portage/ 中的文件而不是通过修改环境变量来变更这些行为！

在 /etc/portage/目录中，你可以创建下列文档：

• package.mask它列出了你永远不希望Portage安装的软件包。
• package.unmask 它列出了本来Gentoo的开发者不建议安装的，但是你希望能安装的软件包。
• package.accept_keywords 它列出了还未被确认适合你的系统或架构，但是你希望能安装的软件包。
• package.use它列出了你希望某些特定软件包使用的而不是整个系统使用的USE标记。

这些并不需要一定是文件；它们也可以是有包含单个软件包信息文件的目录。更多关于 /etc/portage/目录的信息及你能创建的文件的完整列表可以在Portage的手册页中找到：

user $man portage

改变Portage文件和目录的位置

先前提到的配置文件不能保存在其他地方——Portage总是会在这些特定的位置搜索配置文件。不过Portage还用了许多其他的位置来满足不同的目的：编译、保存源代码、保存portage数据库。

所有的这些目的都有众所周知的默认位置，不过你可以根据你自己的喜好通过/etc/portage/make.conf来改变它们。本章中的其他部分将解释Portage使用哪些特定的位置存放它们以及怎样改变它们在你的文件系统中的存放地点。

这篇文档并不是一份全面的参考。如果你需要100%范围的说明，请参看Portage和make.conf的手册页:

user $man portage

user $man make.conf

储存文件

Gentoo ebuild 软件仓库

Gentoo ebuild repository 的默认位置是/var/db/repos/gentoo。这由缺省的 repos.conf 文件定义，位于 /usr/share/portage/config/repos.conf。 要修改默认值，请将此文件复制到 /etc/portage/repos.conf/gentoo.conf 并更改 location 设置。 当将Gentoo ebuild 存储库存储在别处（通过更改此变量）时，不要忘记相应地更改/etc/portage/make.profile 符号链接。

如果你改变了/etc/portage/repos.conf/gentoo.conf里面的location变量，你可能也需要改变下面几个变量，因为它们不会知道location变量的改变。这是Portage处理这些变量的方式导致的：PKGDIR, DISTDIR, and RPMDIR。

预编译二进制包

虽然Portage并不默认使用预编译的二进制包，但却对其有多方面的支持。当你要求Portage使用预编译的二进制包时，它就会在 /var/cache/binpkgs。中寻找它们。这个位置是通过 PKGDIR 变量定义的。

源代码

程序的源代码默认保存于 /var/cache/distfiles。这个位置是通过DISTDIR 变量定义的。

Portage 数据库

Portage将你系统的状态（装了哪些软件包，什么文件属于哪个软件包……）保存在/var/db/pkg。

警告
请勿手动更改系统状态文件！它可能会破坏 Portage 对系统的认知。

Portage缓存

Portage缓存（包括修改时间、虚拟包、依赖关系树信息……）储存在/var/cache/edb。这个位置就是一个缓存：如果你没有正在运行portage相关的程序，你就可以清空它。

编译软件

Portage的临时文件

Portage的临时文件默认保存在/var/tmp/。这是通过 PORTAGE_TMPDIR变量定义的。

编译目录

Portage为每一个它所安装的软件包在/var/tmp/portage/里创建特定的编译目录。这一位置是在 portage/ 中已添加的 PORTAGE_TMPDIR 变量定义。

Live文件系统位置

默认情况下，Portage将所有的文件安装到当前文件系统(/)里。但是你可以通过改变环境变量ROOT来改变它。这在你想要创建一个新的编译镜像时是很有用的。

日志特性

Ebuild日志

Portage能为每一个ebuild建立日志文件，但只有当 PORT_LOGDIR变量设定的位置是portage可写的才行。默认情况下，这个变量没有设定。如果你没有设定 PORT_LOGDIR，你就不会收到当前日志系统报告的任何编译日志，然而你可能收到一些来自新的elog机制的日志。

如果你定义了PORT_LOGDIR并且你也使用 elog，你就将收到编译日志以及elog保存的任何日志，就像下文解释的一样。

Portage通过elog对日志记录提供精确的控制：

• PORTAGE_ELOG_CLASSES: 这是你设置什么信息被记入日志的地方。你可以使用任何用空格分隔的info、warn、error、log和qa的组合。
  • info: 记录下ebuild打印的 "einfo" 信息
  • warn: 记录下ebuild打印的"ewarn" 信息
  • error: 记录下ebuild打印的 "eerror"信息
  • log: 记录下ebuild打印的 "elog"信息
  • qa: 记录下ebuild打印的 "QA Notice"信息

• PORTAGE_ELOG_SYSTEM: PORTAGE_ELOG_SYSTEM：这是用来选择处理日志信息的模块的。如果留空，则日志记录就被取消。你可以使用任何用空格分隔开的save、custom、syslog、mail、save_summary和mail_summary的组合。你必须至少选择一个模块以使用elog。
  • save: 表示将每一个软件包的日志保存在$PORT_LOGDIR/elog中，或者是在$PORT_LOGDIR/没有配置的情况下保存在/var/log/portage/elog 目录下面。
  • custom: 将所有的信息传递给用户在$PORTAGE_ELOG_COMMAND中定义的命令，这将在随后讨论。
  • syslog: 把所有的信息发送给已安装的系统日志软件。
  • mail:把所有的信息传递给用户在$PORTAGE_ELOG_MAILURI中定义的邮件服务器；这将在随后讨论。这一elog的邮件特性需要>=portage-2.1.1。
  • save_summary: 和save类似，不过它把所有的信息保存在$PORT_LOGDIR/elog/summary.log里，或者/var/log/portage/elog/summary.log里，如果$PORT_LOGDIR没有定义的话。
  • mail_summary: 和mail类似，不过它会在emerge结束时把所有的信息在一个邮件里发送出去。.

• PORTAGE_ELOG_COMMAND: 这个仅仅在custom模块被激活时使用。在这里你指定一个命令来处理日志信息。注意，你可以利用两个变量：${PACKAGE}是软件包的名字和版本，而${LOGFILE}是日志文件的绝对路径。这里是一个可能的用法：

代码 PORTAGE_ELOG_COMMAND 默认样本

PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"

• PORTAGE_ELOG_MAILURI:这包含了mail模块的设定，如地址、用户、密码、邮件服务器、端口。默认配置是 “root@localhost localhost” 这里是一个使用smtp服务器的例子，基于用户名和密码认证并使用特定端口(默认端口是25)：

代码 PORTAGE_ELOG_MAILURI默认样本

PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"

• PORTAGE_ELOG_MAILFROM: 允许你配置日志邮件的"from" 地址；如果没有配置的话，默认是"Portage" 。

• PORTAGE_ELOG_MAILSUBJECT: 允许你为日志邮件生成一个主题行。注意你可以使用两个变量：${PACKAGE}将会显示软件包的名子和版本，而${HOST}则是运行Portage的主机的FQDN。

代码 PORTAGE_ELOG_MAILSUBJECT默认样本

PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"

重要
如果你使用Portage-2.0.*中的enotice，你必须完全移除enotice，因为它和elog不兼容。

Portage 配置

如前所述， Portage可以通过许多变量进行配置，这些变量应该在/etc/portage/make.conf中定义，或/etc/portage/的子目录之一。 请参考make.conf和portage手册页，以获取更多和完整的信息：

user $man make.conf

user $man portage

特殊的Build选项

配置和编译器选项

Portage在build应用程序时，将以下变量的内容传递给编译器并生成编译文件：

CFLAGS 和 CXXFLAGS：为C和C++编译定义所需的编译器标志。

CHOST：为应用程序的编译脚本定义用于build的主机信息

MAKEOPTS：传递给make命令，通常用于定义编译期间使用的指令。有关make选项的更多信息可以在make手册页中找到。

USE变量也在配置和编译过程中使用，但在前面的章节中已经详细解释过了。

Merge选项

当Portage合并了某个软件的新版本时，它将从系统中删除旧版本的废弃文件。Portage为用户提供了5秒的延迟，然后才会删除旧版本。这5秒由CLEAN_DELAY变量定义。

通过设置EMERGE_DEFAULT_OPTS，可以告诉emerge在每次运行时使用某些选项。一些有用的选项是—ask， —verbose， —tree等等。

配置文件的保护措施

Portage 的保护路径

如果文件没有保存在受保护的位置，Portage将重新写入软件的新版本提供的配置文件。这些受保护的目录位置利用CONFIG_PROTECT变量进行定义，通常是配置文件的位置。目录列表用空格分隔的。

将在这种受保护位置写入新文件，原来的配置文件将被重命名，并告知用户存在(可假定的)配置文件的新版本。

要了解当前的 CONFIG_PROTECT 设置， 使用 emerge --info 打印并查看：

user $emerge --info | grep ^FEATURES=

有关Portage的配置文件保护的更多信息可在emergence manpage的配置文件部分获得:

user $man emerge

忽略目录

要“取消保护”受保护位置的某些子目录，用户可以使用CONFIG_PROTECT_MASK变量。

下载选项

源地址

当请求的信息或数据在系统上不可用时，Portage将从互联网检索它。各种信息和数据通道的服务器位置由以下变量定义:

GENTOO_MIRRORS：定义包含源代码(distfile)的服务器位置列表。

PORTAGE_BINHOST：定义一个包含系统预构建包的特定服务器位置。

第三个设置涉及到用户用来更新本地Gentoo存储库的rsync服务器的位置。这是在/etc/portage/repos.conf中定义的文件(或该目录内的文件，如果它被定义为目录):

sync-type：定义服务器类型，默认为rsync。

sync-uri： 定义Portage用来获取Gentoo存储库的特定服务器。

The GENTOO_MIRRORS, sync-type, and sync-uri variables can be set automatically through the mirrorselect application. Of course, app-portage/mirrorselect needs to be installed first before it can be used. For more information, see mirrorselect's online help:

root #mirrorselect --help

If the environment requires the use of a proxy server, then the http_proxy, ftp_proxy, and RSYNC_PROXY variables can be declared.

Fetch commands

When Portage needs to fetch source code, it uses wget by default. This can be changed through the FETCHCOMMAND variable.

Portage is able to resume partially downloaded source code. It uses wget by default, but this can be altered through the RESUMECOMMAND variable.

Make sure that the FETCHCOMMAND and RESUMECOMMAND store the source code in the correct location. Inside the variables the \${URI} and \${DISTDIR} variables can be used to point to the source code location and distfiles location respectively.

It is also possible to define protocol-specific handlers with FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.

Rsync settings

It is not possible to alter the rsync command used by Portage to update the Gentoo repository, but it is possible to set some variables related to the rsync command:

PORTAGE_RSYNC_OPTS

Sets a number of default variables used during sync, each space-separated. These shouldn't be changed unless you know exactly what you're doing. Note that certain absolutely required options will always be used even if PORTAGE_RSYNC_OPTS is empty.

PORTAGE_RSYNC_EXTRA_OPTS

Used to set additional options when syncing. Each option should be space separated:

--timeout=<number>

This defines the number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users or individuals with slow computers might want to set this to 300 or higher.

--exclude-from=/etc/portage/rsync_excludes

This points to a file listing the packages and/or categories rsync should ignore during the update process. In this case, it points to /etc/portage/rsync_excludes.

--quiet

Reduces output to the screen.

--verbose

Prints a complete filelist.

--progress

Displays a progress meter for each file.

PORTAGE_RSYNC_RETRIES

Defines how many times rsync should try connecting to the mirror pointed to by the SYNC variable before bailing out. This variable defaults to 3.

For more information on these options and others, please read man rsync.

配置 Gentoo

选择分支

It is possible to change the default branch with the ACCEPT_KEYWORDS variable. It defaults to the architecture's stable branch. More information on Gentoo's branches can be found in the next chapter.

Portage 特性

It is possible to activate certain portage features through the FEATURES variable. The Portage features have been discussed in previous chapters.

Portage behavior

Resource management

With the PORTAGE_NICENESS variable users can augment or reduce the nice value Portage will use while running. The PORTAGE_NICENESS value is added to the current nice value of Portage.

For more information about nice values, see Portage niceness and the nice man page:

user $man nice

Output behavior

The NOCOLOR variable, which defaults to false, defines if Portage should disable the use of colored output.

使用一个分支

稳定版

变量 ACCEPT_KEYWORDS 定义了系统的软件分支。该变量在 /etc/portage/make.conf 文件中设置，默认配置为 stable 分支。在这种情况下，默认值是 mips。

文件 /etc/portage/make.confUsing the stable branch

# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="mips"

我们推荐您只使用默认的稳定软件分支。不过，如果您不是那么注重稳定性，并且愿意向http://bugs.gentoo.org提交一些bug报告来帮助和完善Gentoo，请继续阅读下面的内容。

测试

警告
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 another, 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.

如果您想用最新版本的软件，您可以考虑转向使用测试分支。要让Portage转而使用测试分支的软件，您只需在您的体系结构名称前加上一个 ~符号。

文件 /etc/portage/make.conf使用测试分支

ACCEPT_KEYWORDS="~mips"

例如，要选择针对 mips 体系结构的测试分支，请修改 /etc/portage/make.conf 文件并设定如下内容：

顾名思义，“测试分支”就是带有测试性质的。如果一个包正处于测试中，这代表软件的开发人员认为它虽然已经具有了相当的功能但还没有经过完全的测试。使用这样的软件，您当然可能会第一个发现它的bug，并可以提交一个bug报告来通知相关的开发者。

之后如果您更新系统，您将会发现有大量的包需要更新。要提醒您注意的是：您使用测试分支更新系统后，再想转回使用官方的稳定分支将不是一件容易的事情。

混合使用稳定和测试分支

package.accept_keywords

您可以让Portage使用某些软件的测试分支中的版本，对于系统的其他软件则使用稳定分支。要实现这样的目的，您需要在/etc/portage/package.accept_keywords文件里加入那些软件包的名字及其所属分类的名称。您也可以建立一个同名文件夹，并在里面建立的文件里加入上述内容。

例如，要使用gnumeric属于测试分支中的版本：

文件 /etc/portage/package.accept_keywords混合使用稳定和测试分支gnumeric application例子

app-office/gnumeric

测试特定版本

如果您希望Portage使用测试分支中某软件的特定版本，但后续版本不再这么做，你可以在package.accept_keywords 里加入相应的版本号来实现这个目的。在此情况下您必须使用 = 运算符。您也可以通过使用<=，<，>或>=运算符来指定一个要使用的版本范围。

任何情况下，如果您添加了版本号，您必须使用一个运算符；如果您忽略了版本号，您就不能使用运算符。

在如下的例子中，我们要求Portage接受版本号为1.2.13的gnumeric：

文件 /etc/portage/package.accept_keywords允许gnumeric的测试版本

=app-office/gnumeric-1.2.13

使用被屏蔽的包

package.unmask

重要
Gentoo 的开发者们不支持您使用这个文件。如果您要使用它请千万小心。开发者们可能不会回应有关于package.unmask 和 package.mask 的支持请求。

当一个包被Gentoo的开发者们屏蔽，但你不考虑 package.mask 文件（默认保存于 /var/db/repos/gentoo/profiles/ 目录下）里所陈述的原因，仍然想使用它的话，请在package.mask文件（如果是一个文件夹，就在此文件夹下的文件中）中加入与/etc/portage/package.unmask 里那行一模一样的内容。

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.

比如说，软件包 =net-mail/hotwayd-0.8 被屏蔽了，但是您想解除这个屏蔽，需要做的只是在 package.unmask中加入相同的一行内容就可以了。

文件 /etc/portage/package.unmask使用特定版本

=net-mail/hotwayd-0.8

附注
如果 /var/db/repos/gentoo/profiles/package.mask 中的条目包含一系列软件包版本，则只需要取消屏蔽实际需要的版本即可。 请阅读上一节以了解如何指定版本。

package.mask

当您希望Portage忽略一个特定的软件包或者一个软件包的特定版本，您可以在/etc/portage/package.mask文件（或者此目录下的一个文件）中加入一行适当的内容来屏蔽它。

例如，当您不希望Portage安装比 gentoo-sources-6.6.21 更新版本的内核时，您只需要在package.mask 文件里加入下面一行内容：

文件 /etc/portage/package.maskMask gentoo-sources 高于 6.6.21 的版本

>sys-kernel/gentoo-sources-6.6.21

dispatch-conf

dispatch-conf是一个帮助合并 ._cfg0000_<name>的工具。 ._cfg0000_<name>是由Portage在它要覆盖被CONFIG_PROTECT变量所保护的某个目录里的文件时建立的。

使用 dispatch-conf,能够在合并配置文件并升级更新的同时保持所有更新记录。 dispatch-conf以RCS版本管理系统或是补丁的方式来保存配置文件间的差别。这意味着如果你在升级配置文件犯下错误时，你可以随时退回到你的配置文件的之前版本。

使用 dispatch-conf,，你可以保持配置文件原来的样子，或者使用新的配置文件，你还可以编辑当前文件或交互式地合并更新。除此之外， dispatch-conf,还有一些很棒的特性：

• 可以自动合并仅有注释变更的文件。
• 可自动合并仅有空白符数量的不同的文件。

首先编辑 /etc/dispatch-conf.conf ，并且创建 archive-dir 变量设定的目录，然后执行 dispatch-conf:

root #dispatch-conf

当运行 dispatch-conf的时候，程序会带你把每个改变了的配置文件挨个过一边。按 u来用新配置文件更新（替换）现在的配置文件，然后继续处理下一个。按z来删除新配置文件，然后继续处理下一个。按 n 键让 dispatch-conf 跳转到下一个文件。 这样可以将合并推迟到将来的某个时间。当处理完所有的配置文件之后， dispatch-conf就会退出。你也可以随时按q 来退出。

更多信息，请查阅dispatch-conf手册页。它会告诉你交互式的合并新旧配置文件，编辑新配置文件，检查两个文件间的差异等等。

user $man dispatch-conf

quickpkg

利用quickpkg可以对系统中已安装的包进行打包归档。这些归档文件可以作为预编译包使用。运行quickpkg非常简单：只要加上你想要制作的软件包的名字就可以了。

例如，要打包curl,arts,procps；

root #quickpkg curl orage procps

预编译包会保存在 $PKGDIR 默认为 （/var/cache/binpkgs/ ）。这些包的保存在$PKGDIR/CATEGORY中。

使用 Gentoo 存储库的子集

不含包和类别

可以有选择地更新某些类别/包而忽略其他类别/包。这可以通过在 emerge --sync 步骤中使用 rsync 排除类别/包来实现。

为了使此方法起作用，必须禁用清单验证，这会降低存储库的安全性。要禁用验证，可以在 sys-apps/portage 上禁用 rsync-verify USE 标志或在 Gentoo 存储库的 repos.conf 条目中设置 sync-rsync-verify-metamanifest=no。

在 /etc/portage/make.conf 的 PORTAGE_RSYNC_EXTRA_OPTS 变量中定义包含排除模式的文件的名称：

文件 /etc/portage/make.conf定义排除文件

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

文件 /etc/portage/rsync_excludes排除所有游戏类别

games-*/*

但是请注意，这可能会导致依赖性问题，因为新的、允许的包可能依赖于新的但排除在外的包。

添加非官方 ebuild

定义自定义 ebuild 存储库

Manual creation

It is possible to instruct Portage to use ebuilds that are not officially available through the Gentoo ebuild repository. In order to do so, create a new directory (for instance /var/db/repos/localrepo) in which to store the 3rd party ebuilds. This new repository will require the same directory structure as the official Gentoo repository.

root #mkdir -p /var/db/repos/localrepo/{metadata,profiles}

root #chown -R portage:portage /var/db/repos/localrepo

Next, pick a sensible name for the repository. The next example uses "localrepo" as the name:

root #echo 'localrepo' > /var/db/repos/localrepo/profiles/repo_name

Then define the EAPI used for the profiles within the repository:

root #echo '8' > /var/db/repos/localrepo/profiles/eapi

Tell Portage that the repository master is the main Gentoo ebuild repo, and that the local repository should not be automatically synchronized (as it is not backed by an external source such as an rsync server, git mirror, or other repository type):

文件 /var/db/repos/localrepo/metadata/layout.conf

masters = gentoo
auto-sync = false
thin-manifests = true
sign-manifests = false

Finally, enable the repository on the local system by creating a repository configuration file inside /etc/portage/repos.conf. This will inform Portage of where the custom local repository can be found:

文件 /etc/portage/repos.conf/localrepo.conf

[localrepo]
location = /var/db/repos/localrepo

Optional: Creating a repo using eselect repository

Alternatively, a custom ebuild repository can be quickly created using the eselect repository module (from app-eselect/eselect-repository). In the following example, substitute localrepo with a name of choice:

root #eselect repository create localrepo

Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ...
Repository <ebuild_repository_name> created and added

A bare repository named "localrepo" will be made available at /var/db/repos/localrepo.

使用多个overlay

For those desiring to develop several ebuild repos, test packages before they hit the Gentoo repository, or who want to use unofficial ebuilds from various sources, the app-eselect/eselect-repository package also provides tooling to aid in keeping repositories up to date. See also eselect repository article.

eselect 存储库

例如，要启用 hardened-development overlay：

root #eselect repository enable hardened-development

使用此方法添加的 overlay 随以下命令更新：

root #emerge --sync

非 Portage 维护的软件

使用自维护的 Portage 软件

Sometimes users want to configure, install, and maintain software individually without having Portage automate the process, even though Portage can provide the software titles. Known cases are packages like kernel sources and Nvidia drivers. It is possible to configure Portage so it knows that a certain package is manually installed on the system (and thus take this information into account when calculating dependencies). This process is called injecting and is supported by Portage through the /etc/portage/profile/package.provided file.

For instance, to inform Portage about gentoo-sources-6.6.21 which has been installed manually, add the following line to /etc/portage/profile/package.provided:

文件 /etc/portage/profile/package.providedMarking gentoo-sources-6.6.21 as manually installed

sys-kernel/gentoo-sources-6.6.21

附注
这是一个使用没有 = 运算符的描述版本的文件。

介绍

For most readers, the information received thus far is sufficient for all their Linux operations. But Portage is capable of much more; many of its features are for advanced customization purposes or are only applicable in specific corner cases.

Of course, with lots of flexibility comes a huge list of potential cases. It will not be possible to document them all here. Instead, the goal is to focus on some generic issues which can then be augmented to fit a particular niche. More tweaks and tips such as these can be found across the Gentoo wiki.

Most, if not all, of these additional features can be easily found by digging through the manual pages that are provided with Portage:

user $man portage

user $man make.conf

Finally, know that these are advanced features which, if not configured correctly, can make debugging and troubleshooting much more difficult. Be sure any of these sorts of customization is explicitly mentioned when opening a bug report.

Per-package environment variables

使用 /etc/portage/env

By default, package builds will use the environment variables defined in /etc/portage/make.conf, such as CFLAGS, MAKEOPTS and others. In some cases, it is beneficial to provide different variables for specific packages. To do so, Portage supports the use of the /etc/portage/env directory and /etc/portage/package.env file.

The /etc/portage/package.env file contains a list of packages for which deviating environment variables are needed as well as a specific identifier that indicates to Portage which identifier file to apply. The identifier name is free format. Portage will look for a file with the exactly same case-sensitive name as the identifier. See the following example for more detail.

Example: Using debugging for specific packages

As an example, to enable debugging for the media-video/mplayer package.

Set the debugging variables in a file called /etc/portage/env/debug-cflags. The filename is arbitrarily chosen, but of course the name reflects the purpose of the file, which should make it obvious if reviewing later why the file exists. The /etc/portage/env directory will need created if it does not yet exist:

root #mkdir /etc/portage/env

文件 /etc/portage/env/debug-cflagsSet specific variables for debugging

# Add -ggdb to CFLAGS for debugging 
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

Next, the media-video/mplayer package is 'tagged' to use the new debug identifier in the package.env file:

文件 /etc/portage/package.envUse the debug-cflags identifier for the mplayer package

media-video/mplayer debug-cflags

Hooking into the emerge process

Using /etc/portage/bashrc and affiliated files

When Portage works with ebuilds, it uses a bash environment in which it calls the various build functions (like src_prepare, src_configure, pkg_postinst, etc.). Portage allows system administrators to set up a specific bash environment.

The advantage of using a specific bash environment is that it allows for hooks into the emerge process during each step it performs. This can be done for every emerge (through /etc/portage/bashrc) or by using per-package environments (through /etc/portage/env as discussed earlier).

Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.

To hook in the process, the bash environment can listen to the variables that are always available during ebuild development (such as CATEGORY, P, PF, ...). Based on the values of these variables additional steps and/or functions can be executed.

Example: Updating the file database

In this example, the /etc/portage/bashrc file will be used to call some file database applications in order to ensure their databases are up to date with the system. The applications used in the example are aide (an intrusion detection tool) and updatedb (to use with mlocate), but these are meant as examples. Do not consider this as a guide for AIDE.

To use /etc/portage/bashrc for this case, we need to “hook” in the postinst (after installation of files) and postrm (after removal of files) phases, because that is when the files on the file system have been changed.

文件 /etc/portage/bashrcHooking into the postinst and postrm phases

my_database_update() {
    echo ":: Calling aide --update to update its database"
    aide --update
    echo ":: Calling updatedb to update its database"
    updatedb
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
post_pkg_postinst() { my_database_update; }
post_pkg_postrm() { my_database_update; }

Executing tasks after ebuild repository syncs

Using /etc/portage/postsync.d location

In addition to hooking into the ebuild phases, Portage offers another option for hook functionality: postsync.d. These types of hooks are run after updating, also referred to as syncing, the Gentoo ebuild repository. In order to run tasks after updating the Gentoo repository, put scripts inside the /etc/portage/postsync.d directory. Be sure any files inside the directory have been marked as executable or they will not run.

Example: Running eix-update

If eix-sync was not used to update sync the repository, then it is still possible to update the eix database after running emerge --sync (or emerge-webrsync) by putting a symlink to /usr/bin/eix called eix-update in /etc/portage/postsync.d.

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update

附注
If a different name is chosen, then it needs to be a script that calls /usr/bin/eix-update instead. The eix binary looks at how it has been called to determine which function to execute. If a symlink were created that pointed to eix yet was not called eix-update, it would not run correctly.

Overriding profile settings

Using /etc/portage/profile

By default, Gentoo uses the settings contained in the profile pointed to by /etc/portage/make.profile, which is a symbolic link to the target profile directory. These profiles define both specific settings as well as inherit settings from other profiles (through their parent files).

By using /etc/portage/profile, system administrators can override profile settings such as packages (what packages are considered to be part of the system set), forced USE flags, and more.

Example: Adding nfs-utils to the system set

When using an NFS-based file systems for critical file systems, it might be necessary to mark net-fs/nfs-utils as a system package, which will cause Portage to heavily warn administrators in the event they would attempt to unmerge it.

To accomplish this, the package must be added to the /etc/portage/profile/packages file, prepended with a * (asterisk symbol):

文件 /etc/portage/profile/packagesMarking net-fs/nfs-utils as a system package

*net-fs/nfs-utils

Applying non-standard patches

Patching source code using user patches in /etc/portage/patches/

User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.

Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.

Patches can be dropped into any of the following directories:

• /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
• /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
• /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/

Example: Applying patches to Firefox

The www-client/firefox package is one of the many that already call eapply_user (possibly implicitly) from within the ebuild, so there is no need to override anything specific.

If for some reason (for instance because a developer provided a patch and asked to check if it fixes the bug reported) patching Firefox is wanted, all that is needed is to put the patch in /etc/portage/patches/www-client/firefox/ (it might be best to use the full name and version so that the patch does not interfere with later versions) and rebuild Firefox.