Binary package guide/ko

Next to the usual support for ebuilds, Portage supports building and installing binary packages. This guide explains how to create them, install them, and how to setup a binary package server.

도입부
There are many reasons why some system administrators like using binary package installations in Gentoo.


 * 1) First of all, it allows administrators to keep similar systems updated. Having to compile everything from source can become time consuming. Maintaining several similar systems, possibly some of them with older hardware, can be much easier if only one system has to compile everything from source and the other systems reuse the binary packages.
 * 2) A second reason is to do safe updates. For mission critical systems it is important to stay usable as much as possible. This can be done by a staging server that performs all updates first to itself. Once the staging server is in a good state the updates can then be applied to the critical systems. A variant of this approach is to do the updates in a chroot on the same system and use the binaries created there on the real system.
 * 3) A third reason is as a backup. Often binary packages are the only way of recovering a broken system (i.e. broken compiler). Having pre-compiled binaries around either on a binary package server or locally can be of great help in case of a broken toolchain.
 * 4) Finally, it also supports updating very old systems. The task of updating very old systems can be greatly eased using binary packages. It is usually helpful to install binary packages on old systems because they do not require build time dependencies to be installed/updated. Binaries packages also avoid failures in build processes since they are pre-compiled.

This guide will focus on the following topics:


 * How to create binary packages;
 * How to distribute the packages to clients;
 * How to use binary packages;
 * How to maintain the binary packages.

Near the end a few more advanced topics on dealing with binary packages will be covered.

바이너리 꾸러미 만들기
There are three main methods for creating binary packages:


 * 1) After a regular installation, using the  application;
 * 2) Explicitly during an emerge operation by using the   option;
 * 3) Automatically through the use of the   as a Portage feature.

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

quickpkg 사용하기
The application takes one or more dependency atoms (or package sets) and creates binary packages for all installed packages that match that atom.

For instance, to create binary packages of all installed GCC versions:

To create binary packages of all installed packages on the system, use the  glob:

There is a caveat with this method: 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 (perhaps even confidential) data into the packages, by default does not include configuration files that are protected through the CONFIG_PROTECT method. To force inclusion of configuration files, use the  or   options.

Using --buildpkg as an emerge option
When installing software using, Portage can be asked to create binary packages by using  option:

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 all build time dependencies to be previously installed.

Implementing buildpkg as a Portage feature
The most common way to automatically create binary packages whenever a package is installed by Portage is to use the  feature, which can be set in  like so:

With this feature enabled, every time Portage installs software it will create a binary package as well.

일부 꾸러미 생성 제외
It is possible to tell Portage not to create binary packages for a select few packages or categories. This is done by passing the  option to emerge:

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

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

There is, however, no "out-of-the-box" method provided by Portage for distributing binary packages. Depending on the desired 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 lighttpd and configure it to provide read access to 's PKGDIR location.

Then, on the client systems, configure the PORTAGE_BINHOST variable accordingly:

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

When using SSH, it is possible to use the Portage Linux user's SSH key (without passphraze as the installations need to happen in the background) to connect to a remote binary package host.

To accomplish this, make sure that the Portage user's SSH key is allowed on the server. This will need to happen for each machine that will connect to the SSH capable binary host:

The PORTAGE_BINHOST variable could then look like so:

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

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

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

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


 * The client and server architecture and CHOST must match.
 * The CFLAGS and CXXFLAGS variables 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 to the emerge command upon invocation (see Installing binary packages).

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

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

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

There is a Portage feature that automatically implements the equivalent of  without the need for updating the EMERGE_DEFAULT_OPTS variable:

바이너리 꾸러미 호스트에서 꾸러미 가져오기
When using a binary package host, clients need to have the PORTAGE_BINHOST variable set. Otherwise the client will not know where the binary packages are stored which results in Portage being unable to retrieve them.

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

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

관련 옵션은 입니다. 이 옵션은 바이너리 꾸러미를 타임스탬프를 부여받기 이전에 빌드했을 경우 이머지가 바이너리 꾸러미를 재설치를 고려하지 않도록 합니다. 이 옵션은 바이너리 꾸러미 서버를 처음부터 다시 빌드했지만  옵션을 다른 경우에 활용했을 경우 유용합니다.

추가 클라이언트 설정
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 the PORT_LOGDIR variable has been set and is enabled by default.

몇가지 꾸러미 모음 또는 항목 분류에서 바이너리 꾸러미를 제외하는 유사한 방법으로, 클라이언트에서 꾸러미 모음 또는 항목 분류와 같은 바이너리 꾸러미 설치를 제외하도록 설정할 수 있습니다.

설정을 완료하려면,  옵션을 사용하십시오:

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

오래된 바이너리 꾸러미 제거
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.

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

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

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

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

꾸러미 파일 관리
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 must be recreated. This is done using command:

꾸러미 디렉터리 스냅샷 만들기
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 do not use the packages directory directly but use binary packages from the snapshot.

Snapshots can be created using the or  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.
 * 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.

바이너리 꾸러미 형식 이해
Binary packages created by Portage have the file name ending with. These files consist of two parts:


 * 1) A  archive containing the files that will be installed on the system.
 * 2) A  archive containing package 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  and  files.

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

The xpak file can be examined using the utility.

내용을 조회하려면:

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

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

The file 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.

quickunpkg로 꾸러미 해제하기
Zoobab wrote a simple shell tool named quickunpkg to quickly unpack files.