This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.

Please visit our production wiki at https://wiki.gentoo.org

바이너리 꾸러미 안내서

From Gentoo Wiki (test)
Jump to:navigation Jump to:search
This page is a translated version of the page Binary package guide and the translation is 93% complete.
Outdated translations are marked like this.

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

도입부

There are many reasons why some system administrators like using binary packages for software installations on Gentoo:

  1. It allows administrators to save time when keeping 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 use the binary packages.
  2. Do safe updates. For mission-critical systems in production 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. 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. It aids in 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.

이 안내서에서는, 다음 내용에 집중했습니다:

  • Creating binary packages.
  • Distributing the packages to clients.
  • Implementing binary packages.
  • Maintaining the binary packages.

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

참고
이 안내서에서 다루는 모든 도구는 별도로 명시하지 않는 한, sys-apps/portage의 일부입니다.

바이너리 꾸러미 만들기

바이너리 꾸러미를 만드는 세가지 주요 방법은 다음과 같습니다:

  1. After a regular installation, using the quickpkg application.
  2. Explicitly during an emerge operation by using the --buildpkg (-b) option.
  3. Automatically through the use of the buildpkg value in Portage's FEATURES variable.

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

quickpkg 사용하기

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

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

root #quickpkg sys-devel/gcc

시스템에 이미 설치한 꾸러미의 바이너리 꾸러미를 만들려면 * 글롭을 사용하십시오:

root #quickpkg "*/*"

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

--buildpkg 이머지 옵션 사용하기

When installing software using emerge, Portage can be asked to create binary packages by using --buildpkg (-b) option:

root #emerge --ask --buildpkg sys-devel/gcc

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 --buildpkgonly (-B) option can be used:

root #emerge --ask --buildpkgonly sys-devel/gcc

그러나 후자 방식은 앞서 설치한 빌드 시간 의존성이 필요합니다.

포티지 기능 buildpkg 적용

포티지에서 꾸러미를 언제 설치하든지 바이너리 꾸러미를 자동으로 만드는 일반적인 방법은 다음과 같이 /etc/portage/make.conf buildpkg를 사용하는 방식입니다:

파일 /etc/portage/make.confEnabling Portage's buildpkg feature
FEATURES="buildpkg"

이 기능을 활성화하면, 항상 포티지에서는 프로그램을 설치할 때마다 바이너리 꾸러미도 함께 만듭니다.

일부 꾸러미 생성 제외

몇가지 꾸러미 또는 카테고리는 바이너리 꾸러미를 만들지 않게 할 수 있습니다. 이머지를 수행할 때 --buildpkg-exclude 옵션을 전달하면 됩니다:

root #emerge -uDN @world --buildpkg --buildpkg-exclude "virtual/* sys-kernel/*-sources"

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

바이너리 꾸러미 호스트 설정

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

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

웹기반 바이너리 꾸러미 호스트

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

(lighttpdwww-servers/lighttpd와 같은) 웹 서버를 사용하시고, /etc/portage/make.confPKGDIR 위치 값을 설정하여 읽기 권한을 부여하십시오.

파일 /etc/lighttpd/lighttpd.conflighttpd 설정 예제
# add this to the end of the standard configuration
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/usr/portage/packages/" )

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

파일 /etc/portage/make.confUsing a web-based binary package host
PORTAGE_BINHOST="http://binhost.example.com/packages"

SSH 바이너리 꾸러미 호스트

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

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

To accomplish this, make sure that the root 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:

root #cat root.id_rsa.pub >> /home/binpkguser/.ssh/authorized_keys

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

파일 /etc/portage/make.confSSH 접근 용도로 PORTAGE_BINHOST 설정하기
PORTAGE_BINHOST="ssh://binpkguser@binhostserver/usr/portage/packages"
참고
Do not use the SSH configuration files found in ~/.ssh/config for setting ports or username. This location is ignored when Portage tries to rsync the packages back onto the client. Instead set all the options correctly in the PORTAGE_BINHOST variable.

NFS 내보내기

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

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

파일 /etc/exportsExporting the packages directory
/usr/portage/packages   2001:db8:81:e2::/48(ro,no_subtree_check,root_squash) 192.168.100.1/24(ro,no_subtree_check,root_squash)

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

파일 /etc/fstab꾸러미 폴더 마운트 항목
binhost:/usr/portage/packages      /usr/portage/packages    nfs    defaults    0 0

바이너리 꾸러미 사용하기

다른 시스템에서 바이너리 꾸러미를 쓸만하게 하려면 몇가지 요구조건을 만족해야 합니다:

  • 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 instruction set features (like MMX, SSE, etc.) have to be carefully selected; all clients need to support them.
중요
포티지는 요구사항이 일치하는지 검증할 수 없습니다. 전반적인 설정을 유지하는 것은 시스템 관리자의 책임입니다.

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

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

바이너리 꾸러미 설치

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

Option Description
--usepkg (-k) Tries to use the binary package(s) in the locally available packages directory. Useful when using NFS or SSHFS mounted binary package hosts. If the binary packages are not found, a regular (source-based) installation will be performed.
--usepkgonly (-K) Similar to --usepkg (-k) but fail if the binary package cannot be found. This option is useful if only pre-built binary packages are to be used.
--getbinpkg (-g) Download the binary package(s) from a remote binary package host. If the binary packages are not found, a regular (source-based) installation will be performed.
--getbinpkgonly (-G) Similar to --getbinpkg (-g) but will fail if the binary package(s) cannot be downloaded. This option is useful if only pre-built binary packages are to be used.

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

파일 /etc/portage/make.confAutomatically fetch binary packages and fail the package if not available
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkgonly"

There is a Portage feature that automatically implements the equivalent of --getbinpkg (-g) without the need for updating the EMERGE_DEFAULT_OPTS variable with the --getbinpkg value:

파일 /etc/portage/make.confEnabling getbinpkg in the FEATURES variable
FEATURES="getbinpkg"

바이너리 꾸러미 호스트에서 꾸러미 가져오기

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

파일 /etc/portage/make.confSetting PORTAGE_BINHOST
PORTAGE_BINHOST="http://binhost.example.com/packages"

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

참고
다중 바이너리 꾸러미 서버 지원은 약간 덜 완벽합니다. 동일한 꾸러미 버전에 대해 다양한 서버에서 바이너리 꾸러미를 제공한다면, 처음 서버만을 고려합니다. 각각의 서버에서의 USE 변수 설정과 바이너리 꾸러미 처리 후 시스템 설정에 일치할 USE 변수 설정이 다르다면 문제가 될 수 있습니다.

수정한 바이너리 꾸러미 재설치

Passing the --rebuilt-binaries option to emerge will reinstall every binary that has been rebuilt since the package was installed. This is useful in case rebuilding tools like revdep-rebuild are run on the binary package server.

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

추가 클라이언트 설정

getbinpkg 기능 다음에, 포티지에서는 binpkg-logs 기능을 감지합니다. 이 기능은 바이너리 꾸러미의 성공적인 설치 여부에 대한 기록을 유지해야 할 경우에 대비해 기록을 통제합니다. PORT_LOGDIR 변수 값을 설정하고 기본적으로 활성화 했을 경우에만 해당됩니다.

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

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

root #emerge -uDNg @world --usepkg-exclude "sys-kernel/gentoo-sources virtual/*"

To enable such additional settings for each emerge command, add the options to the EMERGE_DEFAULT_OPTS variable in the make.conf file:

파일 /etc/portage/make.confEnabling emerge settings on every invocation
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-kernel/gentoo-sources virtual/*'"

바이너리 꾸러미 관리

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

오래된 바이너리 꾸러미 제거

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

The following command will remove all binary packages that have no corresponding ebuild in the installed ebuild repositories:

root #eclean packages

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

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

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

root #qpkg -c

꾸러미 파일 관리

Inside the packages directory exists a manifest file called Packages. 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, eclean updates it when it removes binary packages.

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

root #emaint binhost --fix

고급 주제

꾸러미 디렉터리 스냅샷 만들기

상당수의 클라이언트 시스템에 바이너리 꾸러미를 배포하려 할 때, 꾸러미 디렉터리 스냅샷을 만드는 것이 좋습니다. 그렇게 하면 클라이언트 시스템에서는 꾸러미 디렉터리를 바로 사용하지 않지만 스냅샷의 바이너리 꾸러미를 사용합니다.

/usr/lib64/portage/bin/binhost-snapshot 또는 /usr/lib64/portage/python3.3/binhost-snapshot 도구를 활용하면 스냅샷을 만들 수 있습니다. 네 개의 매개변수를 취합니다:

  1. 원본 디렉터리(꾸러미 디렉터리 경로)
  2. 대상 디렉터리(존재하면 안됨)
  3. URI
  4. 바이너리 꾸러미 서버 디렉터리

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

클라이언트 시스템에서 바이너리 꾸러미 서버 디렉터리를 가리키려면 URI를 사용해야 합니다. 해당 위치에서 binhost-snapshot에 주어진 URI로 재참조합니다. 이 URI에는 대상 디렉터리 참조가 들어있습니다.

바이너리 꾸러미 형식 이해

포티지가 만든 바이너리 꾸러미의 파일 이름은 .tbz2로 끝납니다. 이 파일은 두부분으로 나눕니다:

  1. 시스템에 설치할 파일이 있는 .tar.bz2 아카이브
  2. 꾸러미 메타데이터, ebuild, 환경 파일이 있는 xpak 아카이브

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

app-portage/portage-utilstbz2xpak 형식의 파일을 나누거나 만들 수 있는 몇가지 도구가 있습니다.

다음 명령은 tbz2.tar.bz2 파일과 .xpak 파일로 나눕니다:

user $qtbz2 -s <package>.tbz2

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

내용을 조회하려면:

user $qxpak -l <package>.xpak

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

user $qxpak -x package-manager-0.xpak USE

PKGDIR 배치

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

코드 Packages 디렉터리 배치 (버전 2)
PKGDIR
`+- Packages
 +- app-accessibility/
  | +- pkg1-version.tbz2
  | `- pkgN-version.tbz2
 +- app-admin/
  | `- ...
 `- ...

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

quickunpkg로 꾸러미 해제하기

Zoobab이 .tbz2 파일을 빨리 풀어내는 간단한 quickunpkg 명령줄 도구를 작성했습니다.