Handbook:Parts/Working/Portage/ko

포티지로 오신것을 환영함
포티지는 아마도 프로그램 관리에 있어서 가장 주목할만한 혁신 요소가 아닐까 싶습니다. 상당한 유연성과 방대한 기능들로 갖춰진 포티지는 자주 볼 수 있는 최고의 리눅스용 프로그램 관리 도구입니다.

포티지는 온전히 파이썬en 과 배시en 로 작성했기에 사용자들에게 완전히 두 스크립트 언어로 보입니다.

대부분의 사용자들은 도구로 포티지를 다룹니다. 이 장의 내용은 emerge 맨 페이지에서 볼 수 있는 정보를 베끼지 않았습니다. emerge 옵션의 전체 설명은 man 페이지를 참조하십시오:

이빌드
When Gentoo's documentation talks about packages, it means software titles that are available to the Gentoo users through the Gentoo repository. This repository is a collection of ebuilds, files that contain all information Portage needs to maintain software (install, search, query, etc.). These ebuilds reside in by default.

여러분이 관심있는 프로그램 제목에 대해 어떤 동작을 요청할 때마다 시스템의 기반 요소로 ebuild를 사용합니다. 때문에 시스템의 ebuild를 주기적으로 갱신하여 포티지가 새 프로그램과 보안 갱신 등을 알리는 동작은 매우 중요합니다.

Updating the Gentoo repository
The Gentoo repository is usually updated with, a fast incremental file transfer utility. Updating is fairly simple as the command provides a front-end for :

Sometimes firewall restrictions apply that prevent from contacting the mirrors. In this case, update the Gentoo repository through Gentoo's daily generated snapshots. The tool automatically fetches and installs the latest snapshot on the system:

An additional advantage of using is that it allows the administrator to only pull in Gentoo repository snapshots that are signed by the Gentoo release engineering GPG key. More information on this can be found in the Portage features section on fetching validated Gentoo repository snapshots.

프로그램 검색
There are multiple ways to search through the Gentoo repository for software. One way is through itself. By default, returns the names of packages whose title matches (either fully or partially) the given search term.

예를 들어 "pdf"라는 이름을 가진 모든 꾸러미를 검색하려면:

이와 마찬가지로 설명에서 검색하려면  (또는  ) 스위치를 사용하십시오.

많은 정보를 되돌려주는 출력 내용을 살펴보십시오. 확실히 이름표를 붙여놓았기 때문에 의미를 찾아보기 위해 그 이상 들어가지 않겠습니다:

프로그램 설치
원하는 프로그램 이름을 찾았다면 명령으로 프로그램을 쉽게 설치할 수 있습니다. 예를 들어 gnumetric을 설치하려면:

수많은 프로그램이 서로 의존관계가 있기 때문에 어떤 프로그램 꾸러미의 설치를 시도할 때, 이처럼 수많은 의존요소를 설치합니다. 포티지가 의존요소를 잘 관리하니 걱정하지 않으셔도 됩니다. 여러분이 어떤 꾸러미의 설치를 요청할 때 포티지가 설치할 꾸러미를 살펴보려면  스위치를 덧붙이십시오. 예를 들자면:

꾸러미를 설치하는 동안, 포티지는 (필요하다면) 인터넷에서 필요한 소스 코드를 내려받고 기본적으로 에 저장합니다. 그 다음 압축을 풀고 컴파일하고 꾸러미를 설치합니다. 포티지로 꾸러미를 설치하지 않고 소스코드를 다운로드만 하려면 emerge명령에 를 덧붙이십시오:

설치한 꾸러미의 문서 찾기
Many packages come with their own documentation. Sometimes, the  USE flag determines whether the package documentation should be installed or not. To see if the  USE flag is used by a package, use :

The best way of enabling the  USE flag is doing it on a per-package basis via, so that only the documentation for the wanted packages is installed. For more information read the USE flags section.

꾸러미를 설치하고 나면 꾸러미에 대한 문서는 보통 디렉터리의 꾸러미 이름이 달린 하위 디렉터리에서 찾을 수 있습니다. 의 일부인 도구를 사용하면 설치한 모든 파일의 목록을 볼 수 있습니다.

A more sure way to list installed documentation files is to use 's  option. is used to query Portage's database and comes as part of the package:

The  option can be used with other rules to view the install locations for many other types of files. Additional functionality can be reviewed in 's man page:.

프로그램 제거
프로그램 꾸러미를 시스템에서 제거하려면 를 사용하십시오. 설치 이후 바뀐 프로그램의 설정 파일을 제외하고 여러분의 시스템에서 꾸러미로부터 설치한 모든 파일을 제거하도록 포티지에 알립니다. 설정 파일을 남겨서 꾸러미를 다시 설치한다면 꾸러미를 계속 다룰 수 있습니다.

시스템에서 꾸러미를 제거할 때, 프로그램을 설치했을 때 자동으로 설치한 꾸러미의 의존 요소는 그대로 남습니다. 제거할 수 있는 모든 의존요소를 포티지가 찾도록 하려면 emerge의  기능을 사용하십시오. 이 내용은 나중에 문서에서 다루겠습니다.

시스템 업데이트
To keep the system in perfect shape (and not to mention install the latest security updates) it is necessary to update the system regularly. Since Portage only checks the ebuilds in the Gentoo repository, the first thing to do is to update this repository. When the Gentoo repository is updated, the system can be updated using. In the next example, the  option is also used which will tell Portage to display the list of packages it wants to upgrade and ask for confirmation:

포티지는 여러분이 설치한 프로그램의 최신 버전을 찾습니다. 그러나 이는 여러분이 확실히 설치한 프로그램의 버전만을 확인합니다 (프로그램의 목록은 에 있습니다). 이 절차는 의존성까지 철저히 확인하진 않습니다. 의존 요소까지 갱신하려면  옵션을 덧붙이십시오.

하지만 모든 꾸러미를 의미하지 않습니다. 시스템에 있는 일부 꾸러미는 컴파일 및 빌드과정에 필요하지만 꾸러미의 설치가 끝나면 의존성은 더이상 필요치 않습니다. 포티지는 이를 빌드 의존성이라고 부릅니다. 갱신 주기때마다 이들을 포함하려면 를 덧붙이십시오.

여러분은 시스템에 분명하게 설치하지 않(지만 다른 프로그램의 의존요소로서 끌려옵니다)은 꾸러미에서 보안 업데이트를 진행할 때, 이 명령을 가끔씩은 실행해주는 것이 좋습니다.

시스템의 USE 설정을 바꾸었다면, 그에 따라 를 추가하는것이 좋습니다. 포티지는 플래그의 변경으로 새 꾸러미의 설치 또는 존재하는 꾸러미의 재 컴파일이 필요한지를 검증합니다.

메타꾸러미
Some packages in the Gentoo repository don't have any real content but are used to install a collection of packages. For instance, the package will install a complete KDE environment on the system by pulling in various KDE-related packages as dependencies.

이런 꾸러미를 시스템에서 제거할 때 이 꾸러미에 대해 를 실행하면 시스템에 남아있던 의존 효과가 더 이상 남지 않습니다.

포티지는 또한 버려진 의존성을 잘 제거하는 기능을 갖추고 있지만, 프로그램의 가용성은 동적으로 바뀌므로, 우선 USE 플래그를 바꾸었을 때 새로 바뀐 내용을 포함하여 전체 시스템을 업데이트 하는것이 중요합니다. 이 과정을 수행하고 나면 을 실행하여 버려진 의존성을 제거할 수 있습니다. 포티지에 최근 추가한 기능이긴 하지만, 이 절차가 끝나면, 더이상 필요하지 않아 방금 삭제한 프로그램에 동적으로 연결한 프로그램을 다시 빌드해야합니다.

이 모든 과정을 다음 3개의 명령으로 처리합니다:

는  꾸러미에서 제공합니다. 잊지 말고 우선 이머지하십시오

라이선스
Beginning with Portage version 2.1.7, it is possible to accept or reject software installation based on its license. All packages in the tree contain a LICENSE entry in their ebuilds. Running will show the package's license.

기본적으로 포티지는 모든 라이선스를 허용하지만, 읽기를 요구하고 동의서에 동의여부를 확인해야 하는 최종 사용자 사용허가서(EULA)는 제외합니다.

The variable that controls permitted licenses is called ACCEPT_LICENSE, which can be set in the file. In the next example, this default value is shown:

이 설정을 통해 설치 과정상 EULA의 내용을 승인하려 직접 확인해야 하는 프로그램은 설치할 수 없습니다. EULA가 없는 꾸러미를 설치할 수 있습니다.

It is possible to set ACCEPT_LICENSE globally in, or to specify it on a per-package basis in the file.

For example, to allow the license for the  package, add the following to :

This permits the installation of the package, but prohibits the installation of the  package, even though it has the same license.

License groups defined in the ACCEPT_LICENSE variable are prefixed with an  sign. A commonly requested setting is to only allow the installation of free software and documentation. To accomplish this, remove all currently accepted licenses (using ) and then only allow the licenses in the FREE group as follows:

이 경우 "free"는 대부분 보통 FSF나 OSI에서 설명합니다. 이 요구사항을 만나지 않는 라이선스를 가진 꾸러미는 시스템에 설치하지 않습니다.

용어
우리가 이전에 언급한대로라면, 포티지는 굉장히 강력하며 다른 프로그램 관리도구에서 빠진 수많은 기능을 지원한다고 했습니다. 이러한 점을 이해하기 위해, 더 자세히는 말고 적당한 선에서 포티지의 일부 모양새를 설명하도록 하겠습니다.

포티지에서 단일 꾸러미의 각기 다른버전이 시스템에 공존할 수 있습니다. 다른 배포판에서는 버전에 이름을 같이 붙이려 (예를 들자면 freetype과 freetype2와 같이) 하지만, 포티지는 SLOT이라는 용어를 사용합니다. ebuild는 이 버전에 대해 각각의 SLOT을 선언합니다. 제각각의 슬롯이 부여된 ebuild는 시스템에 공존할 수 있습니다. 예를 들어 freetype 꾸러미는 ebuild에 SLOT="1"과 SLOT="2"가 있습니다.

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd, and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied).

Software in the Gentoo repository can reside in different branches. By default the system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although the ebuilds for those software are in the Gentoo repository, Portage will not update them before they are placed in the stable branch.

Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Gentoo repository is unable to verify if the package works on different architectures.

각각의 젠투 설치 과정은 시스템이 제 기능을 수행하는데 필요한 꾸러미 목록과 같은 여러 정보로 이루어진 프로파일을 충실히 따릅니다.

차단 꾸러미
Ebuild에는 의존성에 대해 포티지에 알려줄 특정 내용을 포함하고 있습니다. 이들 중에 두가지 가능한 의존성이 있습니다. 하나는 빌드 의존성에 대해 선언한 DEPEND 변수이며, 다른 하나는 실행시간 의존성에 대해 선언한 RDEPEND 변수입니다. 이들 의존성 중 하나가 호환되지 않는 꾸러미나 가상요소를 분명하게 지목했다면 실행시 막아버립니다.

포티지의 최근 버전은 사용자가 따로 설정하지 않아도 별로 중요하지 않은 차단 같은건 충분히 알아서 잘 처리합니다만 경우에 따라서는 아래에 설명한대로 직접 고쳐야 할 때도 있습니다.

차단 상황을 고치려면, 꾸러미를 설치하지 않거나 차단을 유발하는 꾸러미를 먼저 제거하는 방법 둘 중 하나를 정할 수 있습니다. 주어진 예제에서는, postfix를 설치하지 않거나 ssmtp를 먼저 제거하는 방법을 선택할 수 있습니다.

와 같이 특정 요소에 대한 차단 꾸러미를 볼 수도 있습니다. 이런 경우에는 차단 꾸러미의 최신 버전으로 업데이트 하면 차단이 풀립니다.

아직 설치하지 못한 서로 차단하는 두 꾸러미들에게도 가능한 방법이 있습니다. 이 드문 경우에는 왜 두 꾸러미를 설치해야 하는지를 알아야 합니다. 대부분의 경우 둘 중 하나만 설치할 수 있습니다. 둘 다 설치해야 한다면, 젠투 버그 추적 시스템에 버그를 제출하십시오.

가려놓은 꾸러미
시스템에서 사용할 수 없는 꾸러미를 설치하려 할 때 이런 가려짐 오류가 나타납니다. 시스템에서 쓸 수 있는 다른 프로그램을 설치하려고 하거나 꾸러미가 쓸 수 있는 상태가 될 때까지 기다리셔야 합니다. 꾸러미를 가린 이유는 얼마든지 있습니다:

USE 플래그 변경의 필요성
를 설정하지 않았을 때 다음과 같은 오류메시지가 뜰 때도 있습니다.

다른 꾸러미에만 의존하지 않는 꾸러미를 설치하려 할 때 이런 경고나 오류가 발생하지만, 어떤 USE 플래그 (또는 USE 플래그 모음)로 꾸러미를 반드시 빌드해야 할 필요가 있을때에도 그렇습니다. 주어진 예제에서는 app-text/feelings 꾸러미가 USE="test" 로 빌드해야겠지만 시스템에 이 플래그를 설정하지 않은 상황입니다.

이 문제를 해결하려면 의 전역 USE 플래그에 요구하는 USE 플래그를 추가하거나 에 지정 꾸러미에 대한 플래그를 설정하십시오.

빠진 의존성
시스템에 존재하지 않는 다른 꾸러미에 의존하여 프로그램을 설치하려고 했습니다. 이미 알려진 문제라면 버그질라를 확인해주시고, 없다면 보고해 주십시오. 브랜치를 뒤섞어 엎어놓지 않는한 이 일은 발생하지 않겠지만, 그렇기 때문에 이런 현상은 버그입니다.

애매모호한 이빌드 이름
설치하려는 프로그램이 하나 이상의 꾸러미와 관련된 이름을 지니고 있습니다. 이럴 경우 카테고리 이름을 같이 넣어줘야 합니다. 포티지는 선택할 수 있는 일치 항목을 알려줍니다.

순환 의존성
Two (or more) packages to install depend on each other and can therefore not be installed. This is most likely a bug in one of the packages in the Gentoo repository. Please re-sync after a while and try again. It might also be beneficial to check Bugzilla to see if the issue is known and if not, report it.

가져오기 실패
포티지가 다른 프로그램의 (쓸 수 있는 경우) 설치를 계속하려고 할 때 주어진 프로그램에 대한 소스코드를 내려받을 수 없습니다. 이 문제는 올바르게 동기화 하던 미러가 어긋났다거나 ebuild가 잘못된 위치를 가리켰기 때문에 발생할 수 있습니다. 어떤 이유 때문에 소스 코드가 있는 서버가 먹통이 되었을 수도 있습니다.

문제가 여전히 생기면 몇시간 후 다시 시도하십시오.

시스템 프로파일 보호
시스템의 핵심 꾸러미 제거를 요청했습니다. 이런 메시지가 뜨면 프로파일에서 필요하다고 적어넣은 꾸러미이기 때문에 시스템에서 제거해서는 안되겠습니다.

다이제스트 검증 실패
This is a sign that something is wrong with the Gentoo repository - often, caused by a mistake made when committing an ebuild to the Gentoo ebuild repository.

다이제스트 검증에 실패하면 꾸러미의 다이제스트를 다시 만들지 마십시오. 를 실행해도 문제는 고쳐지지 않습니다. 이렇게하면 대부분 일을 더 꼬이게 합니다!

Instead, wait an hour or two for the repository to settle down. It is likely that the error was noticed right away, but it can take a little time for the fix to trickle down the rsync mirrors. Check Bugzilla and see if anyone has reported the problem yet or ask around on (IRC). If not, go ahead and file a bug for the broken ebuild.

Once the bug has been fixed, re-sync the Gentoo ebuild repository to pick up the fixed digest.