Binary package guide/ko

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

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


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

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

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

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

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

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

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

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

There is a caveat with this method though: it relies on the installed files, which can be a problem in case of configuration files. Administrators often change configuration files after installing software. Because this could leak out important or perhaps even confidential data into the packages,  by default does not include configuration files that are protected through the CONFIG_PROTECT method. To include those as well, use the  or   options.

--buildpkg 이머지 옵션 사용하기
When installing software using, portage can be asked to create binary packages as well by using  :

It is also possible to ask portage to only create a binary package but not to install the software on the live system. For this, the  option can be used:

The latter approach however requires that all build time dependencies are already installed.

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

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

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

This could be used for packages that have little to no benefit in having a binary package available. Examples would be the Linux kernel source packages or upstream binary packages (those ending with -bin like ).

바이너리 꾸러미 호스트 설정
Portage supports a number of protocols for downloading binary packages: FTP, FTPS, HTTP, HTTPS and SSH. This leaves room for many possible binary package host implementations.

There is, however, no out-of-the-box method provided by portage for distributing binary packages. Depending on the requested setup, additional software will need to be installed.

웹기반 바이너리 꾸러미 호스트
A common approach for distributing binary packages is to create a web based binary package host.

Use a web server (such as ) and configure it to provide read access to the  location.

Then, on the clients, configure the  variable accordingly:

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

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

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

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

NFS 내보내기
When using binary packages on an internal network, it might be easier to just export the packages through NFS and mount it on the clients.

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

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

바이너리 꾸러미 사용하기
For binary packages to be usable on other systems they must fulfill some requirements.
 * The client and server architecture and CHOST must match.
 * The  and   that were used to build the binary packages must be compatible with all clients.
 * USE flags for processor specific features (like MMX, SSE,...) have to be carefully selected; all clients need to support them.

Next to these, portage will check if the binary package is built using the same USE flags as expected on the client. If a package is built with a different USE flag combination, portage will either ignore the binary package (and use source-based build) or fail, depending on the options passed on to  (see Installing binary packages).

On clients, a few configuration changes are needed in order for the binary packages to be used.

바이너리 꾸러미 설치
There are a few options that can be passed on to the  command that inform portage about using binary packages.


 * Try to use the binary package(s) in the locally available packages directory. Useful when using NFS-mounted binary package hosts. If the binary package is not found, a regular (source-based) installation will be done.
 * Try to use the binary package(s) in the locally available packages directory. Useful when using NFS-mounted binary package hosts. If the binary package is not found, a regular (source-based) installation will be done.


 * Similar to  but fail if the binary package cannot be found.
 * Similar to  but fail if the binary package cannot be found.


 * Download the binary package from a remote binary package host. If the binary package is not found, a regular (source-based) installation will be done.
 * Download the binary package from a remote binary package host. If the binary package is not found, a regular (source-based) installation will be done.


 * Similar to  but fail if the binary package cannot be downloaded.
 * Similar to  but fail if the binary package cannot be downloaded.

In order to automatically use binary package installations, the appropriate option can be added to the  variable:

There is a portage feature that automatically implements the equivalent of  without the need for updating the   variable: getbinpkg.

바이너리 꾸러미 호스트에서 꾸러미 가져오기
When using a binary package host, clients need to have the  variable set. Otherwise the client will not know where the binary packages are stored (and how to retrieve them).

The  variable uses a space-separated list of URIs. This allows administrators to use several binary package servers simultaneously. The URI must always point to the directory in which the file resides.

수정한 바이너리 꾸러미 재설치
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.

To accomplish this, use the  option:

Maintaining binary packages
Exporting and distributing the binary packages will lead to useless storage consumption if the binary package list is not actively maintained.

오래된 바이너리 꾸러미 제거
In the package an application called   is provided. It allows for maintaining portage-related variable files, such as downloaded source code files, but also binary packages.

The following command will remove all binary packages that have no corresponding ebuild:

For more details please read the Eclean article.

Another tool that can be used is the  tool from the. However, this tool is a bit less configurable.

To clean up unused binary packages (in the sense of used by the server on which the binary packages are stored):

꾸러미 파일 관리
Inside the packages directory, a file called exists. This file acts as a cache for the metadata of all binary packages in the packages directory. The file is updated whenever portage adds a binary package to the directory. Similarly,  updates it when it removes binary packages.

If for some reason binary packages are simply deleted or copied into the packages directory, or the file gets corrupted or deleted, then it needs to be recreated. This is done using :

꾸러미 디렉터리 스냅샷 만들기
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.

The files from the package directory are copied to the target directory. A file is then created inside the binary package server directory (fourth argument) with the provided 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.

Understanding the binary package format
Binary packages created by portage have the file name ending tbz2. These files consist of two parts:
 * 1) an .tar.bz2 archive containing the files that will be installed on the system, and
 * 2) an xpak archive containing the metadata, the ebuild and the environment file.

See  for a description of the format.

In some tools exists that are able to split or create tbz2 and xpak files.

The following command will split the tbz2 into a and an  file:

The xpak file can be examined using.

To list the contents:

The next command will extract a file called which contains the enabled use flags for this package:

The PKGDIR layout
The currently used format version 2 has the following layout:

Packages directory layout (version 2)

The is the major improvement (and also the trigger for portage to know that the binary package directory uses version 2) over the first binary package directory layout (version 1). In version 1, all binary packages were also hosted inside a single directory (called ) and the category directories only had symbolic links to the binary packages inside the directory.

Unpacking with quickunpkg
Zoobab wrote a simple shell tool named quickunpkg to quickly unpack tbz2 files.