Handbook:Parts/Working/Portage/ko

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

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

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

이빌드
꾸러미에 대해 이야기할 때면, 젠투 저장소에서 젠투 사용자들이 사용할 수 있는 프로그램의 제목을 의미합니다. 이 저장소는 포티지가 프로그램을 관리(설치, 검색, 요청 등)하기 위해 필요로 하는 모든 정보가 들어간 ebuild 파일의 모음입니다. 이 ebulid 파일은 기본적으로 안에 있습니다.

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

젠투 저장소 업데이트
보통 젠투 저장소는 빠른 증분 파일 전송 유틸리티 로 업데이트합니다. 명령을 프론트엔드로 제공하는 만큼 포티지 트리 업데이트는 상당히 간단합니다.

방화벽 제한때문에 를 사용할 수 없어도, 매일 만드는 스냅샷으로 젠투 저장소를 업데이트할 수 있습니다. 도구는 시스템에 최신 스냅샷을 가져오고 설치합니다.

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.

Once the package installed, its documentation is generally found in a subdirectory named after the package in the directory:

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의  기능을 사용하십시오. 이 내용은 나중에 문서에서 다루겠습니다.

시스템 업데이트
시스템의 완벽한 모양새를 유지하(고 최신 보안 갱신 요소를 설치하도록 알림을 받지 않으)려면 시스템을 주기적으로 갱신할 필요가 있습니다. 여러분이 처음 젠투 저장소를 새로 고칠 때 젠투 저장소의 이빌드만 확인합니다. 젠투 저장소를 업데이트하면, 로 시스템을 업데이트할 수 있습니다. 다음 예제에서는  스위치를 사용하여 업그레이드할 꾸러미의 목록을 표시하고 계속 할 것인지 물을 것을 포티지에 요청합니다.

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

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

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

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

메타꾸러미
젠투 저장소에서 어떤 꾸러미는 실제 내용을 포함하지는 않지만 꾸러미 모음을 설치하는데 사용합니다. 예를 들어 꾸러미는 의존요소로서의 다양한 KDE 관련 꾸러미를 시스템에 가져와서 완전한 KDE 환경으로 설치합니다.

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

포티지는 또한 버려진 의존성을 잘 제거하는 기능을 갖추고 있지만, 프로그램의 가용성은 동적으로 바뀌므로, 우선 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.

ACCEPT_LICENSE 변수에 정의한 라이선스 그룹은 기호가 붙습니다. 일반적으로 요청하는 설정은 자유 소프트웨어 및 자유 문서의 설치만 허용하는 설정입니다. 이렇게 하려면 현재 허용하는 라이선스를 제거하고 다음과 같이 자유 그룹에 속한 라이선스만 허용하십시오:

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

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

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

동일한 기능을 가지고 있으나 다른 방식으로 구현한 꾸러미도 있습니다. metalogd, sysklogd, syslog-ng 같은 경우는 모두 시스템 로거입니다. "시스템 로거" 기능에 따른 프로그램이지, 의존할 수 있는 프로그램은 아닙니다. 예를 들어, 다른 시스템 로거로서 metalogd는 바람직한 선택중 하나입니다. 포티지에서는 가상 요소를 허용합니다. 각 시스템 로거는 virtual 분류 항목의 logger 가상 꾸러미에 "배타적"인 로깅 서비스 의존성으로 참조하므로 이 프로그램은 꾸러미에 의존할 수 있습니다. 가상 꾸러미를 설치하면, 로깅 꾸러미를 이미 설치하지 않았다면 (이 경우 가상 꾸러미를 고려함) 꾸러미에서 언급한 첫 로깅 꾸러미를 끌어옵니다.

젠투 저장소에 있는 프로그램은 다른 브랜치에 둘 수 있습니다. 기본적으로 시스템에서는 젠투에서 안정적인 꾸러미로 간주하는 꾸러미만 받아들입니다. 대부분의 새 프로그램 제목을 제출하면 시험 브랜치에 추가하며, 안정화 상태로 표시하기 전에 수많은 시험 과정이 필요함을 의미합니다. 젠투 저장소에 이 프로그램에 대한 이빌드가 존재하지만, 포티지에서 안정 브랜치에 올려놓기 전에는 업데이트하지 않습니다.

일부 프로그램은 일부 아키텍처에서만 쓸 수 있습니다. 또는 다른 아키텍처에서 동작하지 않거나, 시험이 더 필요하거나 다른 아키텍처에서 꾸러미가 동작하는지 젠투 저장소에 제출한 프로그램을 개발자가 시험할 수 없기도 합니다.

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

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

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

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

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

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

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

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

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

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

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

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

순환 의존성
설치하려는 두가지 (이상) 의 꾸러미가 서로 의존성을 가져 설치할 수 없습니다. 거의 젠투 저장소의 버그일 수 있습니다. 조금 지난 후 다시 트리를 동기화 한 다음 재시도하십시오. 또한 이미 알려진 문제라면 버그질라를 확인할 수 있는데, 없다면 보고하십시오.

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

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

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

다이제스트 검증 실패
이는 젠투 저장소에 뭔가 문제가 있다는 이야기입니다. 보통 젠투 이빌드 저장소에 이빌드를 제출할 때 실수하여 발생하는 문제입니다.

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

대신 저장소 상태가 바로 잡힐 때까지 한두시간 정도 기다려보십시오. 올바르지 않은 방법으로 오류가 나타났을 수도 있는 것이지만, rsync 미러가 서서히 자리를 잡는데 시간이 좀 걸릴 수가 있습니다. 기다리는 동안에 버그질라를 확인해보시고 누군가가 이 문제를 보고했는지 찾아보거나 에서 질문하십시오. 만약 내용이 없다면 가서 깨진 이빌드의 문제를 알려주십시오.

문제점을 고치고 나면, 젠투 이빌드 저장소를 다시 동기화 하여 수정한 다이제스트를 받으십시오.