Handbook:Parts/Portage/Files/ru

Конфигурационные файлы
Portage поставляется с настройками по умолчанию, которые хранятся. Все настройки Portage обрабатываются с помощью переменных. Какие переменные использует Portage и для чего они нужны будет описано позже.

Так как многие директивы отличаются между архитектурами, к Portage также есть настроечный файл по умолчанию, который является частью системного профиля. Этот профиль указывается с помощью симлинка ; конфигурации Portage устанавливаются из файлов профиля и всех вышестоящих профилей. Мы объясним позже о профилях и каталоге.

Если требуется изменить конфигурационные переменные, не меняйте или. Вместо этого используйте файл, который имеет больший приоритет над предыдущими файлами. Для получения дополнительной информации прочитайте. Как следует из названия, это просто пример; Portage не использует этот файл.

Также можно определить конфигурационные переменные в переменном окружении, но мы не рекомендуем этого делать.

Информация из определенного профиля
Мы уже ознакомились с каталогом. На самом деле это не каталог, а симлинк на один из профилей, по умолчанию это, однако можно создать свои собственные профили где угодно и ссылаться на них. Профиль, на который указывает симлинк, и есть системный профиль.

Профиль содержит информацию о конкретной архитектуре для Portage, например, список пакетов, которые принадлежат этому системному профилю, список пакетов, которые не работают (или замаскированы) в этом системном профиле, и так далее.

Пользовательская конфигурация
Если нужно изменить поведение Portage относительно того, как устанавливается программное обеспечение, то правильным будет настроить файлы в. Настоятельно рекомендуется использовать файлы в и очень не рекомендуется переопределять поведение Portage в переменном окружении!

Пользователи могут создать в следующие файлы:
 * список пакетов, которые Portage никогда не будет устанавливать
 * список пакетов, которые Portage будет устанавливать, даже если разработчик Gentoo отговаривает пользователей от их установки
 * список пакетов, которые Portage будет устанавливать, даже если они не подходят для используемой системы или архитектуры (пока)
 * список пакетов, для которых необходимо использовать специфичные USE-флаги, а не брать системные USE-флаги

Не обязательно они должны быть файлами; это могут быть каталоги, содержащие по одному файлу для пакета. Больше информации о каталоге и весь список возможных файлов, которые можно создать там, можно найти в man-странице Portage:

Изменение файлов Portage и расположение каталогов
The previously mentioned configuration files cannot be stored elsewhere - Portage will always look for those configuration files at those exact locations. However, Portage uses many other locations for various purposes: build directory, source code storage, Portage tree location, ...

All these purposes have well-known default locations but can be altered to personal taste through. The rest of this chapter explains what special-purpose locations Portage uses and how to alter their placement on the filesystem.

This document isn't meant to be used as a reference though. To get 100% coverage, please consult the Portage and make.conf man pages:

Дерево Portage
The Portage tree default location is. This is defined by the PORTDIR variable. When storing the Portage tree elsewhere (by altering this variable), don't forget to change the symbolic link accordingly.

After changing the PORTDIR variable, it is recommended to alter the following variables as well since they will not notice the  PORTDIR change. This is due to how Portage handles variables: PKGDIR,  DISTDIR ,  RPMDIR.

Двоичные пакеты
Even though Portage doesn't use prebuilt binaries by default, it has extensive support for them. When asking Portage to work with prebuilt packages, it will look for them in. This location is defined by the PKGDIR variable.

Исходный код
По умолчанию исходный код для приложений хранится в каталоге. Этот каталог определяется переменной DISTDIR.

База Portage
Portage хранит статус системы (какие пакеты установлены, какие файлы какому пакету принадлежат, ...) в каталоге.

Кеш Portage
Кэш Portage (с временем изменений, виртуальными пакетами, информации о зависимостях в дереве, ...) хранится в. Там располагается просто кэш: пользователи спокойно могут отчистить это каталог, если на данный момент не запущено никаких приложений Portage.

Временные файлы Portage
Временные файлы Portage по умолчанию хранятся в. Этот каталог определяется с помощью переменной PORTAGE_TMPDIR.

When altering the PORTAGE_TMPDIR variable, it is recommended to also change the following variables as well since they will not notice the PORTAGE_TMPDIR change. This is due to how Portage handles variables: BUILD_PREFIX.

Каталог сборки
Portage creates specific build directories for each package it emerges inside. This location is defined by the BUILD_PREFIX variable.

Расположение реальной системы
По умолчанию Portage устанавливает все файлы на текущую файловую систему, но это можно изменить, если настроить переменную окружения ROOT. Что весьма удобно, в случае создания новых сборочных образов.

Журналироване для ebuild
Portage can create per-ebuild log files, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (through the Portage user). By default this variable is unset. If PORT_LOGDIR is not set, then there will not be any build logs with the current logging system, though users may receive some logs from the new support.

If PORT_LOGDIR is not defined and is used, then build logs and any other logs saved by elog will be made available, as explained below.

Portage offers fine-grained control over logging through the use of elog:


 * PORTAGE_ELOG_CLASSES : This is where users can define what kinds of messages to be logged. This can be any space-separated combination of info, warn, error, log, and qa.
 * info: Logs "einfo" messages printed by an ebuild
 * warn: Logs "ewarn" messages printed by an ebuild
 * error: Logs "eerror" messages printed by an ebuild
 * log: Logs the "elog" messages found in some ebuilds
 * qa: Logs the "QA Notice" messages printed by an ebuild


 * PORTAGE_ELOG_SYSTEM : This selects the module(s) to process the log messages. If left empty, logging is disabled. Any space-separated combination of save, custom, syslog, mail, save_summary, and mail_summary can be used. At least one module must be used in order to use elog.
 * save: This saves one log per package in, or if $PORT_LOGDIR is not defined.
 * custom: Passes all messages to a user-defined command in $PORTAGE_ELOG_COMMAND; this will be discussed later.
 * syslog: Sends all messages to the installed system logger.
 * mail: Passes all messages to a user-defined mailserver in $PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features of elog require >=portage-2.1.1.
 * save_summary: Similar to save, but it merges all messages in, or if $PORT_LOGDIR is not defined.
 * mail_summary: Similar to mail, but it sends all messages in a single mail when emerge exits.


 * PORTAGE_ELOG_COMMAND : This is only used when the custom module is enabled. Users can specify a command to process log messages. Note that the command can make use of two variables: ${PACKAGE} is the package name and version, while ${LOGFILE} is the absolute path to the logfile. For instance:


 * PORTAGE_ELOG_MAILURI : This contains settings for the mail module such as address, user, password, mail server, and port number. The default setting is "root@localhost localhost". The following is an example for an SMTP server that requires username and password-based authentication on a particular port (the default is port 25):


 * PORTAGE_ELOG_MAILFROM : Allows the user to set the "from" address of log mails; defaults to "Portage" if unset.


 * PORTAGE_ELOG_MAILSUBJECT : Allows the user to create a subject line for log mails. Note that it can make use of two variables: ${PACKAGE} will display the package name and version, while ${HOST} is the fully qualified domain name of the host Portage is running on. For instance: