바이너리 꾸러미 안내서

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Binary package guide and the translation is 19% complete.
Outdated translations are marked like this.
Other languages:
Portage - the heart of Gentoo
emerge — configuration — ebuild repository — dispatch-conf

world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles
See also
See the Gentoo Binary Host Quickstart article for information on using pre-built binary packages from the Gentoo binary package host. That article should cover everything needed to easily use the binary packages from the public Gentoo binhost.

This guide covers in-depth binary package creation, distribution, use, and maintenance, and a few more advanced topics near the end.

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

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

Why use binary packages on Gentoo?

일부 시스템 관리자가 젠투에서 바이너리 패키지 설치를 좋아하는 이유는 몇가지가 있습니다.

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

Binary package formats

Two binary package formats for use in Gentoo exist, XPAK and GPKG. Starting with v3.0.31, Portage supports the new binary package format GPKG. The GPKG format solves issues with the legacy XPAK format and offers the benefit of new features, however it is not backward compatible with the legacy XPAK format.

System administrators using older versions of Portage (<=v3.0.30) should continue to use the legacy XPAK format, which is Portage's default setting on those versions.

Motivation for the newer GPKG format design can be found in GLEP 78: Gentoo binary package container format. Bugs bug #672672 and bug #820578 also provide helpful details.

To instruct Portage to use the GPKG format, change the BINPKG_FORMAT value in /etc/portage/make.conf. Note that current versions of Portage use gpkg by default.

파일 /etc/portage/make.confSpecify GPKG binary package format
BINPKG_FORMAT="gpkg"

This guide mostly applies to both formats; where this is not the case it will be noted. See the Understanding the binary package format section for technical details on the binary package formats themselves.

바이너리 꾸러미 사용하기

General prerequisites

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

  • 클라이언트와 서버 아키텍처 및 CHOST 설정이 일치해야 합니다.
  • 바이너리 꾸러미를 빌드하는데 사용했던 CFLAGS와 CXXFLAGS값이 다른 클라이언트와 호환되어야합니다.
  • 프로세서별 기능에 해당하는 USE 플래그(MMX, SSE 같은 경우)는 조심스럽게 선택해야 합니다. 모든 클라이언트에서 해당 USE 플래그를 지원해야합니다.
참고
Binary packages that are distributed as part of Gentoo's official Binhost project use a minimum instruction set and conservative compiler settings in order to be as widely usable as possible. By way of example, amd64 keyworded packages are built with -march=x86-64 -mtune=generic, which works for any machine which runs the x86-64 (amd64) instruction set.
중요
포티지는 요구사항이 일치하는지 검증할 수 없습니다. 전반적인 설정을 유지하는 것은 시스템 관리자의 책임입니다.

Handling *FLAGS in detail

The app-misc/resolve-march-native utility can be used to find a subset of CFLAGS that is supported by both the server and client(s). For example, the host might return:

user $resolve-march-native
 -march=skylake -mabm -mrtm --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=12288

While the client might return:

user $resolve-march-native
 -march=ivybridge -mno-rdrnd --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=3072

In this example CFLAGS could be set to -march=ivybridge -mno-rdrnd since -march=ivybridge is a full subset of -march=skylake. -mabm and -mrtm are not included as these are not supported by the client. However, -mno-rdrnd is included as the client does not support -mrdrnd. To find which -march's are subsets of others, check the gcc manual, if there is no suitable subset set e.g. -march=x86-64.

Optionally, it is also possible to set -mtune=some-arch or -mtune=native to tell gcc to tune code to a specific arch. In contrast to -march, the -mtune argument does not prevent code from being executed on other processors. For example, to compile code which is compatible with ivybridge and up but is tuned to run best on skylake set CFLAGS to -march=ivybridge -mtune=skylake. When -mtune is not set it defaults to whatever -march is set to.

When changing -march to a lower subset for using binary packages on a client, a full recompilation is required to make sure that all binaries are compatible with the client's processor, to save time packages that are not compiled with e.g. gcc/clang can be excluded:

user $emerge -e @world --exclude="acct-group/* acct-user/* virtual/* app-eselect/* sys-kernel/* sys-firmware/* dev-python/* dev-java/* dev-ruby/* dev-perl/* dev-lua/* dev-php/* dev-tex/* dev-texlive/* x11-themes/* */*-bin"

Similarly, app-portage/cpuid2cpuflags can be used to find a suitable subset of processor specific instruction set USE flags. For example, the host might return:

user $cpuid2cpuflags
 CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3

While the client might return:

user $cpuid2cpuflags
 CPU_FLAGS_X86: avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

In this example CPU_FLAGS_X86 can be set to avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 in /etc/portage/make.conf because these flags are supported by both the client and the host

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

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

바이너리 꾸러미 설치

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

옵션 설명
---usepkg
(-k)		 로컬에 packages 디렉터리가 존재하는 경우 바이너리 꾸러미 사용을 시도합니다. NFS 또는 SSHFS로 마운트한 바이너리 꾸러미 호스트를 사용할 경우 쓸모있습니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.
--usepkgonly
(-K)		 --usepkg (-k) 옵션과 유사하지만 바이너리 꾸러미를 찾지 못하면 실패로 되돌립니다.
--getbinpkg
(-g)		 원격 바이너리 꾸러미 호스트에서 바이너리 꾸러미를 다운로드합니다. 바이너리 꾸러미를 찾지 못하면 일반(소스코드 기반) 설치 방식으로 진행합니다.
--getbinpkgonly
(-G)		 --getbinpkg (-g) 옵션과 유사하지만 바이너리 꾸러미를 다운로드할 수 없으면 실패로 되돌립니다. 이 옵션은 미리 빌드한 바이너리 꾸러미를 사용할 때 쓸모있습니다.

| --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 fetching binary packages and fail if not available
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkgonly"

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

파일 /etc/portage/make.confgetbinpkg 포티지 기능 활성화
FEATURES="${FEATURES} getbinpkg"

Note that this is not equivalent to --getbinpkg (-g) in the EMERGE_DEFAULT_OPTS variable. Especially, --getbinpkg=n on the command line won't override the feature.

Verify binary package OpenPGP signatures

중요
OpenPGP signing and verification is only available for the GPKG binpkg format.

Portage will try to verify the binary package's signature whenever possible, but users must first set up trusted local keys. app-portage/getuto can be used to set up a local trust anchor and update the keys in /etc/portage/gnupg. Portage calls getuto automatically with --getbinpkg or --getbinpkgonly.

This configures portage such that it trusts the Gentoo Release Engineering keys as also contained in the package sec-keys/openpgp-keys-gentoo-release for binary installation purposes.

Changes to the configuration can be done as root using gpg with the parameter --homedir=/etc/portage/gnupg. This way allows importing additional signing keys (e.g. for non-standard installation sources) and declare them as trusted.

To add a custom signing key:

  1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
  2. Run getuto if it has never run:
    root #getuto
  3. Use gpg --homedir=/etc/portage/gnupg --import public.key to import the public key in portage's keyring.
  4. Trust and sign this key using the key created by getuto. In order to do this, first get the password to unlock the key at /etc/portage/gnupg/pass, then use:
    root #gpg --homedir=/etc/portage/gnupg --edit-key YOURKEYID
    Type sign, yes, paste (or type) the password. The key is now signed. To trust it, type trust, then 4 to trust it fully. Finally, type save.
  5. Update the trustdb so that GPG considers the key valid:
    root #gpg --homedir=/etc/portage/gnupg --check-trustdb

If you hit any issues, check if a pre-existing /etc/portage/gnupg existed. If it did, move it away and then repeat the above steps.

Congratulations, Portage now has a working keyring!

중요
Trusting the key marginally or less will not work

By default, Portage will only verify GPG signatures when a signature file is found in a package, which allows the user to mix signed and unsigned GPKG binary packages from different sources, and allows to use old XPAK format binary packages.

If the user wishes to force signature verification, the binpkg-request-signature feature needs to be enabled. This feature assumes that all packages should be signed and rejects any unsigned package. Note that this feature does not support per-binhost configuration.

파일 /etc/portage/make.confEnabling Portage's binpkg-request-signature feature
# Require that all binpkgs be signed and reject them if they are not (or have an invalid sig)
FEATURES="binpkg-request-signature"

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

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

When using a binary package host, clients need to have the PORTAGE_BINHOST variable set in /etc/portage/make.conf or the sync-uri variable in /etc/portage/binrepos.conf. Without this configuration, the client will not know where the binary packages are stored which results in Portage being unable to retrieve them.

파일 /etc/portage/binrepos.confSetting binhost sync-uri
[binhost]
sync-uri = https://example.com/binhost
priority = 10

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

Many Gentoo stages already come with a preinstalled /etc/portage/binrepos.conf file, which points to the corresponding binary packages generated during the stage builds.

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

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

emerge에 전달할 --rebuilt-binaries 옵션은 설치한 꾸러미에서 다시 빌드한 모든 바이너리를 다시 설치합니다. 이 옵션은 바이너리 꾸러미 서버에서 revdep-rebuild 또는 python-updater와 같은 도구를 다시 빌드할 때 써먹을만합니다.

관련 옵션은 --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/*'"

Updating packages on the binary package host

중요
Do not use --changed-use(-U) when updating packages on the binary package host, doing so will cause packages with added or removed USE flags to be skipped, which will cause their installation from binary package on the client to fail due to non-matching USE between the source ebuild and binary package (if the client's --binpkg-respect-use=y, the default). Use --newuse(-N), which will always rebuild packages even for added or removed USE flags, ensuring the binary package stays in sync with the source ebuild.

바이너리 꾸러미 만들기

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

  1. 일반 설치 과정 후, quickpkg 사용하기
  2. --buildpkg (-b) 옵션으로 emerge 처리 과정에 명시하기
  3. 포티지 기능에 buildpkg값을 넣어 자동으로 처리하기

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

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

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

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

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

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

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

포티지 기능 buildpkg 적용

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

파일 /etc/portage/make.conf포티지 buildpkg 기능 활성화
FEATURES="${FEATURES} buildpkg"

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

일부 꾸러미 생성 제외

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

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

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

Binary package compression formats

It is possible to use a specific compression type on binary packages. Currently, the following formats are supported: bzip2, gzip, lz4, lzip, lzop, xz, and zstd. Defaults to zstd. Review man make.conf and search for BINPKG_COMPRESS for the most up-to-date information.

The compression format can be specified via make.conf.

파일 /etc/portage/make.confSpecify binary package compression format
BINPKG_COMPRESS="lz4"

Note that the compression type used might require extra dependencies to be installed, for example, in this case app-arch/lz4.

Binary package OpenPGP signing

중요
OpenPGP signing and verification is only available for the GPKG binpkg format.

A PGP signature enables Portage to check the creator and integrity of a binary package, and to perform trust management based on PGP keys. The binary package signing feature is disabled by default. To use it, enable the binpkg-signing feature. Note that whether this feature is enabled does not affect the signature verification feature.

파일 /etc/portage/make.confEnabling Portage's binpkg-signing feature
FEATURES="binpkg-signing"

Users also need to set the BINPKG_GPG_SIGNING_GPG_HOME and BINPKG_GPG_SIGNING_KEY variables for Portage to find the signing key.

파일 /etc/portage/make.confConfiguring Portage's signing key
BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="0x1234567890ABCDEF"

Portage will only try to unlock the PGP private key at the beginning. If the user's key will expire over time, then consider enabling gpg-keepalive to prevent signing failures.

파일 /etc/portage/make.confEnabling Portage's gpg-keepalive feature
FEATURES="gpg-keepalive"
요령
gpg-agent by default expires cache entries after 2 hours. This means that, by default, if an emerge session lasts longer than 2 hours, signing of binpkgs will eventually fail regardless of FEATURES="gpg-keepalive". To prevent this problem, set max-cache-ttl to some large value (e.g. 34560000) in $BINPKG_GPG_SIGNING_GPG_HOME/gpg-agent.conf.

quickpkg 사용하기

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

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

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

root #quickpkg sys-devel/gcc

To create binary packages for the system set:

root #quickpkg @system

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

root #quickpkg "*/*"

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

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

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

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

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

HTTPD

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

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

Caddy

To set up the Caddy HTTP server to provide a web-based binary package host, create a Caddyfile containing:

파일 Caddyfile
x.x.x.x:80 { # Replace x.x.x.x with your host's IPv4 address
    root * /path/to/binhost/var/cache/binpkgs
    file_server browse # Needed to server 
}

Once that is created, run Caddy with:

root #caddy run --config /path/to/Caddyfile

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

파일 /etc/portage/make.conf웹기반 바이너리 꾸러미 호스트 사용하기
PORTAGE_BINHOST="http://binhost.genfic.com/packages"

SSH 바이너리 꾸러미 호스트

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

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

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

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

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

파일 /etc/portage/make.confSSH 접근 용도로 PORTAGE_BINHOST 설정하기
PORTAGE_BINHOST="ssh://binpkguser@binhostserver/usr/portage/packages"

If the SSH server is listening to a different port (e.g 25), then it must be specified after the address, like so:

파일 /etc/portage/make.confSetting PORTAGE_BINHOST for SSH access on port 25
PORTAGE_BINHOST="ssh://binpkguser@binhostserver:25/var/cache/binpkgs"
참고
포티지에서 꾸러미를 클라이언트에 전달할 때 포트와 사용자 이름을 무시하므로 ~/.ssh/config를 사용하지 마십시오. 대신 PORTAGE_BINHOST 변수에 모든 옵션을 올바르게 설정하십시오.

NFS 내보내기

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

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

파일 /etc/exports꾸러미 디렉터리 내보내기
/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 NFS share is mounted on the local filesystem, so there is no need to set PORTAGE_BINHOST or use the --getbinpkg option. Instead, follow the normal procedures for installing binary packages, remembering to point PKGDIR to the NFS share so that portage knows where to find the packages:

파일 /etc/portage/make.confSetting the package directory for portage
PKGDIR="/var/cache/binpkgs"
참고
If PKGDIR is network-mounted, it may be advantageous to enable FEATURES="pkgdir-index-trusted". This feature disables checking the entire PKGDIR for added or removed packages and instead trusts the contents of the Packages file to be accurate. This significantly improves performance on high-latency networks.

바이너리 꾸러미 관리

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

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

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

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

root #eclean packages

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

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

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

root #qpkg -c

꾸러미 파일 관리

요령
As of portage-3.0.52, Portage defaults to FEATURES=pkgdir-index-trusted for performance, which requires an accurate Packages index. This can be disabled if it is an inconvenience to regularly fix up the index with emaint after manual changes.

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

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

root #emaint binhost --fix

To clear the cache of all binary packages:

root #rm -r /var/cache/binpkgs/*

고급 주제

Chrooting

If creating packages for a different Portage profile or system with different USE flags, a chroot can be created.

참고
This example uses /var/chroot/buildenv as the chroot path, but any path can be used.

Creating the directories

First, the directories for this chroot must be created:

root #mkdir --parents /var/chroot/buildenv

Deploying the build environment

Next, the appropriate stage 3 tarball must be downloaded and extracted, here the desktop profile | openrc tarball is being used:

This can be extracted with the following command:

/var/chroot/buildenv/ #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner

Configuring the build environment

중요
{{{1}}}

The build environment should be configured to match that of the system it is building for. The simplest way to do this is to copy the /etc/portage and /var/lib/portage/world files. This can be done with rsync:

참고
This command should be executed on the build target machine, where the remote host has the chroot.
user $rsync --archive --whole-file --verbose /etc/portage/* larry@remote_host:/var/chroot/buildenv/etc/portage
user $rsync --archive --whole-file --verbose /var/db/repos/* larry@remote_host:/var/chroot/buildenv/var/db/repos
참고
{{{1}}}

This process should be repeated for the world file:

user $rsync --archive --whole-file --verbose /var/lib/portage/world larry@remote_host:/var/chroot/buildenv/var/lib/portage/world
참고
/var/lib/portage and /var/lib/portage/world should have the root:portage permissions.

Configuring the chroot

Once created, mounts must be bound for the chroot to work:

/var/chroot/buildenv #mount --types proc /proc proc
/var/chroot/buildenv #mount --rbind /dev dev
/var/chroot/buildenv #cp --dereference /etc/resolv.conf etc
참고
If a tmpfs is being used for portage's temp dir, ensure that is mounted.

Entering the chroot

To enter this chroot, the following command can be used:

/var/chroot/buildenv #chroot . /bin/bash

Optionally, the prompt can be set to reflect the fact that the chroot is active:

/ #export PS1="(chroot) $PS1"
Performing an initial build
참고
This step assumes this configuration has been completed: Setting portage to use buildpkg.

This step is optional, but rebuilds all packages in the new world:

(chroot) #emerge --emptytree @world

Building for other architectures

crossdev is a tool to easily build cross-compile toolchains. This is useful to create binary packages for installation on a system whose architecture differs from that of the system used to build the packages. A common example would be building binary packages for a device like an arm64 Raspberry Pi from a more powerful amd64 desktop PC.

An installation guide for sys-devel/crossdev can be found at the crossdev page.

Build a cross compiler

Using crossdev with the following command can build a toolchain for the desired system:

root #crossdev --stable -t <arch-vendor-os-libc>

For the rest of this section, the example target will be for a Raspberry Pi 4:

root #crossdev --stable -t aarch64-unknown-linux-gnu

After this has built, a toolchain will have been created in /usr/aarch64-unknown-linux-gnu, and will look like a bare-bones Gentoo install where it is possible to edit Portage settings as normal.

요령
Replacing aarch64-unknown-linux-gnu with aarch64-unknown-linux-musl would build a system with the Musl libc rather than Glibc.

Basic setup

Removing the -pam flag from the USE line in /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf is generally recommended in a setup like this:

파일 /usr/aarch64-unknown-linux-gnu/etc/portage/make.confDisable the pam USE flag
CHOST=aarch64-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
 
ROOT=/usr/${CHOST}/
 
ACCEPT_KEYWORDS="${ARCH}"
 
USE="${ARCH}"
 
CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
 
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Ensure pkgs from another repository are not overwritten
PKGDIR=${ROOT}var/cache/binpkgs/
 
#If you want to redefine PORTAGE_TMPDIR uncomment (and/or change the directory location) the following line
PORTAGE_TMPDIR=${ROOT}var/tmp/
 
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/var/db/repos/local/"

Profiles

List available profiles for the device by running:

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile list

Next, select the profile that best suits:

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile set <profile number>

Build a single package

To build a single binary package for use on the device, use the following:

root #emerge-aarch64-unknown-linux-gnu --ask foo

Build world file

To build every package in the world file, then the following command is needed:

root #emerge-aarch64-unknown-linux-gnu --emptytree @world

Binary location

By default, all binary packages will be stored in /usr/aarch64-unknown-linux-gnu/var/cache/binpkgs, so this is the location needed to be selected when setting up a binary package host.

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

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

/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에는 대상 디렉터리 참조가 들어있습니다.

바이너리 꾸러미 형식 이해

XPAK format

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

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

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

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

다음 명령은 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

GPKG format

GPKG format binary packages created by Portage have the file name ending with .gpkg.tar. These files consist of four parts at least:

  1. A gpkg-1 empty file that used to identify the format.
  2. A C/PV/metadata.tar{.compression} archive containing package metadata, the ebuild, and the environment file.
  3. A C/PV/image.tar{.compression} archive containing the files that will be installed on the system.
  4. A Manifest file containing checksums to protect against file corruption.
  5. Multiple optional .sig files containing OpenPGP signature are used for integrity checking and verification of trust.

The format can be extracted by tar without the need for additional tools.

PKGDIR 배치

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

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

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

In portage-3.0.15 and later, FEATURES=binpkg-multi-instance is enabled by default:

코드 Packages directory layout (version 2 + FEATURES=binpkg-multi-instance)
PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1/
 |    +- pkg1-version-build_id.xpak
 |    `- pkgN-version-build_id.xpak
 +- app-admin/
 |  `- ...
 `- ...

quickunpkg로 꾸러미 해제하기

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

See also

External resources

quickpkg man page.

Retrieved from "https://wiki.gentoo.org/index.php?title=Binary_package_guide/ko&oldid=1356439"