Handbook:Parts/Portage/Files/ko

설정 지시문
포티지 기본 설정은 에 저장합니다. 모든 포티지 설정은 변수에 저장합니다. 어떤 변수들을 포티지에서 살펴보는지 이들이 나중에 어떤 의미를 지니고 있는지는 나중에 설명하겠습니다.

Since many configuration directives differ between architectures, Portage also has default configuration files which are part of the system profile. This profile is pointed to by the symlink; Portage' configurations are set in the  files of the profile and all parent profiles. We'll explain more about profiles and the directory later on.

When changing a configuration variable, do not alter or. Instead use which has precedence over the previous files. For more information, read the. As the name implies, this is merely an example file - Portage does not read in this file.

It is also possible to define a Portage configuration variable as an environment variable, but we don't recommend this.

프로파일별 정보
We've already encountered the directory. Well, this is not exactly a directory but a symbolic link to a profile, by default one inside although one can create their own profiles elsewhere and point to them. The profile this symlink points to is the profile to which the system adheres.

A profile contains architecture-specific information for Portage, such as a list of packages that belong to the system corresponding with that profile, a list of packages that don't work (or are masked-out) for that profile, etc.

사용자별 설정
When Portage's behavior needs to be changed regarding the installation of software, then the right set of files inside will need to be changed. It is highly recommended to use files within and highly discouraged to override the behavior through environment variables!

Within users can create the following files:
 * which lists the packages that Portage should never try to install
 * which lists the packages Portage should be able to install even though the Gentoo developers highly discourage users from emerging them
 * which lists the packages Portage should be able to install even though the package hasn't been found suitable for the system or architecture (yet)
 * which lists the USE flags to use for certain packages without having the entire system use those USE flags

이들 요소가 꼭 파일일 필요는 없습니다. 꾸러미 각각에 포함한 단 하나의 파일이어도 됩니다. 디렉터리와 이곳에 만들 수 있는 모든 파일 목록에 대한 더 많은 내용은 포티지 맨페이지에 있습니다.

Changing Portage file and directory locations
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, ...

이들 목적은 잘 알려진 기본 위치를 보유하지만 에서 개인 취향에 따라 바꿀 수 있습니다. 이 절의 나머지 부분에서는 어떤 특수 목적의 위치를 포티지에서 사용하는지 파일 시스템의 해당 위치를 어떻게 바꾸는지 설명합니다.

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:

포티지 트리
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.

소스 코드
Application source code is stored in by default. This location is defined by the DISTDIR variable.

포티지 데이터베이스
포티지는 (어떤 꾸러미를 설치했는지, 꾸러미에 어떤 파일이 속해있는지 등) 시스템의 상태를 에 저장합니다.

포티지 캐시
The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in. This location really is a cache: users can clean it if they are not running any Portage-related application at that moment.

임시 포티지 파일
Portage's temporary files are stored in by default. This is defined by the PORTAGE_TMPDIR variable.

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.

라이브 파일 시스템 위치
By default Portage installs all files on the current filesystem, but this can be changed by setting the ROOT environment variable. This is useful when creating new build images.

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: