Handbook:Parts/Working/Portage/ko

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

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

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

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

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

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

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

를 사용하는 또 다른 장점은 관리자가 젠투 출시 엔지니어링 GPG키로 서명한 포티지 트리 스냅샷만 가져올 수 있다는 점입니다. 이에 대한 자세한 내용은 포티지 기능의 검증된 포티지 트리 스냅샷 가져오기에서 찾으실 수 있습니다.

프로그램 검색
프로그램을 포티지 트리에서 검색하는 방법에는 여러가지가 있습니다. 그중 한가지는 로 찾는 방법입니다. 기본적으로 가 제시한 단어에 일치하는 이름을 가진 꾸러미의 이름을 반환합니다.

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

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

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

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

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

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

설치한 꾸러미의 문서 찾기
대부분의 꾸러미는 문서가 딸려옵니다. 때로는, doc USE 플래그가 꾸러미의 문서를 설치할 지 말 지를 결정합니다. doc USE 플래그를 꾸러미에서 사용하는지 확인하려면 명령을 사용하십시오.

doc USE 플래그를 활성화하는 가장 좋은 방법은 에서 꾸러미마다 활성화하여 여러분이 얻고자 하는 해당 꾸러미의 문서를 가져오는 것입니다. 더 많은 내용을 보고자 한다면 USE 플래그 장을 읽어보십시오.

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

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

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

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

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

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

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

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

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

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

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

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

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

라이선스
포티지 버전 2.1.7부터 라이선스를 기반으로 하여 프로그램 설치를 수락 혹은 거절할 수 있습니다. 트리상의 모든 꾸러미는 ebuild에 LICENSE 엔트리를 가지고 있습니다. 을 실행하면 꾸러미의 라이선스를 알려줍니다.

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

허용할 라이선스를 제어하는 변수는 에 설정할 수 있는 ACCEPT_LICENSE 입니다. 다음 예제에서는 기본값을 나타냅니다:

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

에 전체적으로 를 설정하거나 각 꾸러미를 기반으로 에 지정할 수 있습니다.

예를 들어 의 라이선스를 허용하려면, 에 다음을 추가하십시오:

이를 통해 라이선스를 가진 truecrypt 버전을 설치하지만,  라이선스를 가진 프로그램은 설치하지 않습니다.

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

이 경우 "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가 잘못된 위치를 가리켰기 때문에 발생할 수 있습니다. 어떤 이유 때문에 소스 코드가 있는 서버가 먹통이 되었을 수도 있었습니다.

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

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

다이제스트 검증 실패
이는 포티지 트리에 뭔가 문제가 있다는 이야기입니다. 개발자가 꾸러미를 트리로 커밋할 때 자주 실수하기 때문입니다.

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

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

Once the bug has been fixed, re-sync the Portage tree to pick up the fixed digest.