Binary package guide/ko

일상의 ebuild 지원 요소 말고도, 포티지에서는 바이너리 꾸러미 빌드 및 설치를 지원합니다. 이 안내서에서는 바이너리 꾸러미를 만들고, 설치하는 방법, 그리고 바이너리 꾸러미 서버를 설정하는 방법을 설명합니다.

도입부
관리자가 젠투의 바이너리 꾸러미 설치를 선호하는 몇가지 이유가 있습니다.


 * 1) 무엇보다도, 관리자가 유사 최신 시스템을 유지할 수 있습니다. 모든 소스코드를 컴파일 한다는 건 상당한 시간 소모를 야기합니다. 일부가 느려질 가능성이 있다 하더라도 하나의 시스템에서 모든 소스코드를 컴파일 하고 다른 시스템에서는 바이너리 꾸러미를 재사용할 수 있을 경우 수많은 유사 시스템을 관리하는 일이 굉장히 쉬워질 수 있습니다.
 * 2) 두번째 이유는 안전한 업데이트 수행입니다. 임무가 중요한 시스템에서는 가능한한 사용 가능한 상태를 유지하는 것이 중요합니다. 이 작업은 모든 업데이트를 우선 처리하는 스테이지 서버에서 처리할 수 있으며, 스테이지 서버 상태가 괜찮아지면 중요한 시스템에 적용할 수 있습니다. 다른 접근 방식으로는, 동일 시스템 내에서의 chroot 환경의 업데이트로 처리하고 실제 시스템에 만든 바이너리를 사용하는 방법이 있습니다.
 * 3) 세번째 이유는 백업으로서의 의미가 있기 때문입니다. 가끔은 바이너리 꾸러미가 망가진 시스템(예: 컴파일러 망가짐)을 복구하는 유일한 수단이 될 수 있습니다. 바이너리 꾸러미 서버든, 로컬 머신 어디든 바이너리 꾸러미를 둔다면 굉장한 도움이 될 수 있습니다.
 * 4) 마지막으로, 이 방식은 상당히 오래된 시스템의 업데이트를 지원합니다. 바이너리 꾸러미를 활용하면 굉장히 오래된 시스템을 업데이트 하는 작업을 매우 쉽게 처리할 수 있습니다. 설치하고 업데이트할 빌드 타임에 관계없이 바이너리 꾸러미를 쉽게 설치할 수 있으며, 빌드 과정상의 실패 상황을 피해갈 수 있습니다.

이 안내서에서는, 다음 내용에 집중했습니다
 * 바이너리 꾸러미 만들기
 * 바이너리 꾸러미를 클라이언트에 배포하기
 * 바이너리 꾸러미 사용하기
 * 바이너리 꾸러미 유지 관리하기

바이너리 꾸러미를 다루는 몇가지 고급주제를 더 다루는 것으로 마치겠습니다.

바이너리 꾸러미 만들기
바이너리 꾸러미를 만드는 세가지 주요 방법은 다음과 같습니다:
 * 1) 일반 설치 과정 후,   사용하기
 * 2)   옵션으로 emerge 처리 과정에 명시하기
 * 3) 포티지 FEATURES 변수에  값을 넣어 자동으로 처리하기

이 모든 세가지 방식은  변수에서 가리치는 디렉터리에 바이너리 꾸러미를 만듭니다(기본값은 ).

quickpkg 사용하기
프로그램은 하나 이상의 의존 요소(또는 꾸러미 집합)를 취하며, 일치하는 모든 설치한 꾸러미에 대한 바이너리 꾸러미를 만듭니다.

예를 들어, 설치한 모든 GCC 버전에 대해 바이너리 꾸러미를 만든다면:

모든 기 설치 꾸러미의 바이너리 꾸러미를 만들려면  글롭을 사용하십시오:

이 방식을 활용하는데 있어 위험성을 내포하고 있습니다. 설정 파일에서 문제가 될 수 있는 설치 파일에 의존합니다. 관리자는 종종 프로그램을 설치한 후 설정 파일을 편집합니다. 이 방법은 중요한 또는 비밀 데이터를 꾸러미에 포함할 수 있기 때문에 는 기본적으로 CONFIG_PROTECT 방식을 통해 보호한 설정 파일은 포함하지 않습니다. 마찬가지로 설정 파일을 포함하려면,  또는   옵션을 사용하십시오.

--buildpkg 이머지 옵션 사용하기
로 프로그램을 설치할 때, 를 사용하여 포티지에게 바이너리 꾸러미를 만들도록 요청할 수 있습니다:

바이너리 꾸러미를 만들기만 하고 라이브 시스템에 소프트웨어를 설치하지 않도록 요청할 수 있습니다. 이렇게 하려면  옵션을 활용하시면 됩니다:

그러나 후자 방식으로 접근할 경우 빌드시 의존 관계가 걸린 요소를 모두 설치해야 합니다.

buildpkg 기능을 활용하여 자동으로 처리하기
대부분의 일반적인 방법은 로 언제 패키지를 설치했든지간에 바이너리 꾸러미를 자동으로 만드는 것입니다. 이렇게 하려면, 다음과 같이 의 FEATURES에 buildpkg를 설정하면 됩니다:

포티지가 프로그램을 설치할 때마다, 마찬가지로 바이너리 꾸러미를 만듭니다.

일부 꾸러미 생성 제외
일부 꾸러미 또는 카테고리를 선택하여 포티지가 바이너리 꾸러미를 만들지 않게 할 수 있습니다. 이머지 과정에서  옵선을 사용하면 됩니다:

이 방법은 존재하는 바이너리 패키지를 취하는데 조금 또는 어떠한 이득조차도 없이 꾸러미를 취득하는데 활용할 수 있습니다. 리눅스 커널 소스 꾸러미 또는 업스트림 바이너리 꾸러미가 예가 될 수 있습니다(과 같이 -bin으로 끝나는 꾸러미).

바이너리 꾸러미 호스트 설정
포티지는 바이너리 꾸러미를 다운로드할 다양한 프로토콜, FTP, FTPS, HTTP, HTTPS, SSH를 지원합니다. 이 특징은 바이너리 꾸러미 호스트 구현에 대한 다양한 가능성의 여지를 남겨놓았습니다.

그러나 포티지에서는 바이너리 꾸러미 배포에 있어 특별한 방식을 제공하는 것은 아닙니다. 요청한 설정에 따라 추가 프로그램을 설치할 필요가 있습니다.

웹기반 바이너리 꾸러미 호스트
바이너리 꾸러미를 배포하는 일반적인 접근 방식은 웹기반 바이너리 꾸러미 호스트를 만드는 것입니다.

(와 같은) 웹 서버를 사용하시고,  위치 값을 설정하여 읽기 권한을 부여하십시오.

다음, 클라이언트에서 이 설정값에 맞춰  값을 설정하십시오:

SSH 바이너리 꾸러미 호스트
바이너리 꾸러미를 인증 방식으로 제공하려면 SSH 사용을 고려할 수 있습니다.

SSH를 사용할 때, 원격 바이너리 꾸러미 호스트로 연결할 경우 리눅스 사용자의 SSH 키를(설치 과정처럼 뒤에서 무슨 일로 처리해야 할 경우 암호 없이) 사용할 수 있습니다.

이 과정을 수행하려면, 포티지 사용자의 SSH 키를 서버에서 허용했는지 확인해야 합니다:

변수 값은 다음과 같이 바뀔 수 있습니다:

NFS 내보내기
내부 네트워크에서 바이너리 꾸러미를 사용한다면, NFS를 통해 꾸러미를 내보내고 클라이언트에서 마운트하는 일련의 과정이 쉽습니다.

파일은 다음과 같이 바꿀 수 있습니다:

이 과정이 끝나면 클라이언트에서는 해당 위치를 마운트할 수 있습니다. 예제 항목은 다음과 같습니다:

바이너리 꾸러미 사용하기
다른 시스템에서 바이너리 꾸러미를 쓸만하게 하려면 몇가지 요구조건을 만족해야 합니다.
 * 클라이언트와 서버 아키텍처 및 CHOST 설정이 일치해야 합니다.
 * 바이너리 꾸러미를 빌드하는데 사용했던 와  값이 다른 클라이언트와 호환되어야합니다.
 * 프로세서별 기능에 해당하는 USE 플래그(MMX, SSE 같은 경우)는 조심스럽게 선택해야 합니다. 모든 클라이언트에서 해당 USE 플래그를 지원해야합니다.

그 다음, 포티지에서는 클라이언트에서 바라는 USE 플래그와 바이너리 꾸러미에서 사용하는 USE 플래그가 동일한지 점검합니다. 포티지에서는 에 전달한 옵션에 따라 바이너리 꾸러미를 무시하(며 소스코드 기반 빌드를 활용)하거나 실패로 돌리기도 합니다(바이너리 꾸러미 설치 참고).

클라이언트쪽에서는, 사용할 바이너리 꾸러미에 대한 약간의 설정을 바꾸기만 하면 됩니다.

바이너리 꾸러미 설치
바이너리 꾸러미를 사용하도록 포티지에 안내하려  명령에 전달할 수 있는 몇가지 옵션이 있습니다.


 * 로컬에 꾸러미 디렉터리가 존재하는 경우 바이너리 꾸러미 사용을 시도합니다. NFS로 마운트한 바이너리 꾸러미 호스트를 사용할 경우 쓸모있습니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.
 * 로컬에 꾸러미 디렉터리가 존재하는 경우 바이너리 꾸러미 사용을 시도합니다. NFS로 마운트한 바이너리 꾸러미 호스트를 사용할 경우 쓸모있습니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.


 * 옵션과 유사하지만 바이너리 꾸러미를 찾지 못하면 실패로 되돌립니다.
 * 옵션과 유사하지만 바이너리 꾸러미를 찾지 못하면 실패로 되돌립니다.


 * 원격 바이너리 꾸러미 호스트에서 바이너리 꾸러미를 다운로드합니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.
 * 원격 바이너리 꾸러미 호스트에서 바이너리 꾸러미를 다운로드합니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.


 * 옵션과 유사하지만 바이너리 꾸러미를 다운로드할 수 없으면 실패로 되돌립니다.
 * 옵션과 유사하지만 바이너리 꾸러미를 다운로드할 수 없으면 실패로 되돌립니다.

바이너리 꾸러미 설치를 자동으로 활용한다면,  변수에 적당한 옵션 값을 추가할 수 있습니다:

변수 값을 업데이트할 필요 없이  옵션과 같은 기능을 자동으로 수행하는 getbinpkg 포티지 기능이 있습니다.

바이너리 꾸러미 호스트에서 꾸러미 가져오기
바이너리 꾸러미 호스트를 사용할 때, 클라이언트에서는  변수값을 설정해야 합니다. 그렇지 않으면 바이너리 꾸러미가 어디에 저장되어 있는지 모릅니다(그리고 어떻게 가져오는 지도 모릅니다).

변수는 공백 구분 URI 값을 사용합니다. 이를 통해 관리자가 다양한 바이너리 꾸러미 서버를 동시에 활용할 수 있습니다. URI는 항상 반드시 파일이 위치한 디렉터리를 가리켜야합니다.

수정한 바이너리 꾸러미 재설치
The  option to   will reinstall every binary that has been rebuild since the package was installed. This is useful in case rebuilding tools like  or   are run on the binary package server.

A related option is. It causes emerge not to consider binary packages for a re-install if those binary packages have been built before the given time stamp. This is useful to avoid re-installing all packages, if the binary package server had to be rebuild from scratch but  is used otherwise.

추가 클라이언트 설정
Next to the getbinpkg feature, portage also listens to the binpkg-logs feature. This one controls if log files for successful binary package installations should be kept. It is only relevant if  is set and is enabled by default.

Similar to excluding binary packages for a certain set of packages or categories, clients can be configured to exclude binary package installations for a certain set of packages or categories.

원하고자 하는 바를 이루려면,  옵션을 사용하십시오:

바이너리 꾸러미 관리
바이너리 꾸러미를 내보내고 배포하는 작업은 실제로 바이너리 꾸러미 목록을 유지하지 않을 경우 불필요한 저장소 낭비를 초래할 수 있습니다.

오래된 바이너리 꾸러미 제거
꾸러미에서 이라고 하는 프로그램을 제공합니다. 이 프로그램에서는 포티지 관련 변수 파일을 관리할 수 있게 하는데 다운로드한 소스코드 파일 뿐만 아니라 바이너리 꾸러미에 대해서도 관리합니다.

다음 명령은 ebuild에 관계없는 모든 각각의 바이너리 꾸러미를 제거합니다:

자세한 내용은 Eclean 게시물을 읽어보십시오.

활용할 수 있는 또 다른 도구로는 의 가 있습니다. 그러나 이 도구는, 설정할 수 있는 범위가 약간 좁습니다.

(바이너리 꾸러미를 저장한 서버에서 사용하는 개념 차원에서)사용하지 않는 바이너리 꾸러미를 지우려면:

꾸러미 파일 관리
꾸러미 디렉터리 내부에 라는 파일이 있습니다. 이 파일은 꾸러미 디렉터리의 모든 바이너리 꾸러미 메타데이터 캐시로 동작합니다. 포티지가 바이너리 꾸러미를 디렉터리에 추가할 때마다 파일을 업데이트합니다. 이와 비슷하게 에서 바이너리 꾸러미를 제거할 때  파일을 업데이트합니다.

어떤 이유로 인해 바이너리 꾸러미를 단순하게 삭제했거나 꾸러미 디렉터리로 복사했다든지, 파일이 깨졌다거나 삭제됐다면, 다시 만들어야 합니다. 이 작업은 로 처리할 수 있습니다:

꾸러미 디렉터리 스냅샷 만들기
When deploying binary packages for a large number of client systems it might become worthwhile to create snapshots of the packages directory. The client systems then don't use the packages directory directly but use binary packages from the snapshot.

Snapshots can be created using the tool. It takes four arguments,
 * 1) a source directory (the path to the packages directory),
 * 2) a target directory (that must not exist),
 * 3) a URI, and
 * 4) a binary package server directory.

꾸러미 디렉터리의 파일은 대상 디렉터리로 복사합니다. 그 다음 주어진 URI의 바이너리 꾸러미 서버 디렉터리(네번째 매개변수)에 파일을 만듭니다.

Client systems need to use an URI that points to the binary package server directory. From there they will be redirected to the URI that was given to. This URI has to refer to the target directory.

바이너리 꾸러미 형식 이해
포티지가 만든 바이너리 꾸러미의 파일 이름은 tbz2로 끝납니다. 이 파일은 두부분으로 나눕니다:
 * 1) 시스템에 설치할 파일을 보관한 .tar.bz2 파일
 * 2) 메타데이터, ebuild, 환경 파일을 보관한 .xpak 파일

파일 형식의 설명을 보려면  를 참고하십시오.

에 tbz2와 xpak 형식의 파일을 나누거나 만들 수 있는 몇가지 도구가 있습니다.

다음 명령은 tbz2를 파일과  파일로 나눕니다:

을 활용하여 xpak 파일을 검사할 수 있습니다.

내용을 조회하려면:

다음 명령은 이 꾸러미에 대한 USE 플래그를 활성화 하는 파일의 압축을 풉니다:

PKGDIR 배치
현재 사용하는 버전 2 형식은 다음 배치를 따릅니다:

Packages 디렉터리 배치 (버전 2)

는 첫 바이너리 꾸러미 디렉터리 배치(버전 1)에 비해 주된 개선이 이루어진 부분(이며 버전 2를 사용하는 바이너리 꾸러미 디렉터리를 확인하는 포티지기능의 시발점입니다). 버전 1에서는 모든 바이너리 꾸러미를 단일 디렉터리(이라고 함)에서 제공했으며, 항목 분류 디렉터리에는 디렉터리에 있는 바이너리 꾸러미의 심볼릭 링크만 지니고 있었습니다.

quickunpkg로 꾸러미 해제하기
Zoobab이 tbz2 파일을 빨리 풀어내기 위해 quickunpkg라고 하는 간단한 명령줄 도구를 작성했습니다.