From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Ebuild repository and the translation is 7% complete.
Outdated translations are marked like this.

An ebuild repository is a file-structure that can provide packages for installation on a Gentoo system. Ebuild repositories contain ebuilds, eclasses, and other types of descriptive metadata files that supply Portage with packages, news items, profile targets, etc.

The Gentoo ebuild repository is Gentoo Linux's primary and official ebuild repository - it contains all the information needed to build and install every package that makes up Gentoo. Additional ebuild repositories, such as GURU, can be configured with Portage, to provide even more packages.

Portage will install the latest available version of a package from any configured ebuild repository, by default. If the latest available version is provided by several ebuild repositories, it will be chosen according to a set order of priority - hence the colloquial name overlay.

Administrators of Gentoo systems can configure additional ebuild repositories with Portage by using the utilities and methods described below.

젠투 리눅스에서, 사용자는 이미 "주" 꾸러미 저장소를 보유하고 있습니다. 주 저장소에는 젠투 개발자가 관리하는 모든 프로그램 꾸러미(이빌드)가 들어있습니다. 추가 꾸러미 트리는 보통 "저장소"로 제공합니다. 사용자는 시스템에 저장소(이전에 "오버레이"로 알려짐)를 추가할 수 있습니다.

The Gentoo ebuild repository contains ebuild files that tell Portage how to build and install each package. The ebuilds come with metadata, dependency information, and everything else needed to get a package in working order.

The metadata provides the package's name, version, where to get sources from, available USE flags, license, website etc. Dependency information in ebuilds allows Portage to pull in any other packages required to build and run a package that is to be installed - no more, no less. Dependencies are very granular in Gentoo, they will even vary depending on what use flags are selected, for ultimate selectivity. Perhaps most importantly, ebuilds contain the information required to configure, build (compile), install, and test each package - usually from a project's own source code.

In addition to ebuilds, the Gentoo ebuild repository contains the official profiles, which define the default state of USE flags, default values for most variables found in /etc/portage/make.conf, the set of system packages, etc.

The Gentoo ebuild repository is also the place where news items are posted, which is why any new news items will be highlighted after a Gentoo ebuild repository synchronization.

The Gentoo ebuild repository, and it's ebuilds, are maintained by the Gentoo developers and other members of the community.

The Gentoo ebuild repository will sometimes be called by shorter, or even colloquial, names, such as the Gentoo repository, the Gentoo repo, ::gentoo, gentoo.git, or occasionally just the "repo". It is also historically and commonly known within the Gentoo community as the Portage tree, rsync tree, or sometimes just "the tree".
GURU is an official ebuild repository maintained collaboratively by Gentoo users, with a little help from a few Gentoo developers. It is complimentary to the Gentoo ebuild repository, and the maintainers strive to keep up a reasonable level of quality for the packages provided. There is also a list of public ebuild repositories registered on repos.gentoo.org.

Where do ebuild repositories come from?

Because an ebuild repository is simply a structure of files and directories, a new ebuild repository can be made available to Portage simply by copying those files and directories to a location known to Portage. The ebuild repositories and their files are usually under /var/db/repos/, but the location of repositories configured for Portage is specified in /etc/portage/repos.conf. Ebuild repositories can be configured on any accessible filesystem however, even on an nfs or SSHFS filesystem - allowing them to be stored on a network or Internet server.

As previously discussed, the Gentoo ebuild repository is hosted on gitweb.gentoo.org. That server also hosts other ebuild repositories.

In practice, any additional ebuild repositories usually aren't just copied to a directory by hand and configured for Portage (meaning added to /etc/portage/repos.conf). Generally, new repositories are made available by third parties, and once configured for Portage, are synchronized by Portage. Synchronization mirrors all the files from a remote location to a locally available filesystem, as configured.

Because ebuild repositories are just file-structures, many methods can be used to synchronize them, and Portage offers several possibilities. Rsync is the default synchronization method, git is also popular. The synchronization method is specified in /etc/portage/repos.conf when configuring a repository, along with the information needed to retrieve it.

가용 프로그램

Use the eselect repository tool to easily add, disable, or remove ebuild repositories configured with Portage. This tool also provides a handy way to list and add repositories available through being registered on repos.gentoo.org.

Ebuild repositories can always be configured manually, by editing /etc/portage/repos.conf.

While the Gentoo ebuild repository is either written or reviewed by Gentoo developers, and the GURU repository has some developer oversight, that is not always the case for other ebuild repositories. It is possible that some ebuild repositories might contain vulnerable, badly broken or, theoretically, even malicious software.

New ebuild repositories for use with Portage can also be created by the user.

우선순위가 붙은 ebuild 저장소 목록은 (Repositories 문자열로 찾아서) 다음 출력 목록으로 볼 수 있습니다:

user $emerge --info --verbose
user $portageq repos_config /

Installing packages from other repositories

Packages from repositories other than the Gentoo ebuild repository can be installed with the emerge command, just as usual.

For example, once the GURU repository is added, to install the x11-misc/xbanish package from that repository:

root #emerge --ask x11-misc/xbanish
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 2.96 s.
[ebuild   R   #] x11-misc/xbanish-1.7::guru  0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Note that the repository is not specified in the command. The "::guru" appended to the package atom in the output shows what repository the package will be installed from. This works because the x11-misc/xbanish package is present in the GURU repository, but not in the Gentoo repository.

If multiple versions of the same package are available from two or more different ebuild repositories, Portage will install the most recent version.


각각의 ebuild 저장소에는 유일의 우선순위가 있습니다. 여러 ebuild 저장소에 특정 버전을 발견했을 경우 확인하며, 해결 방법은 혼란스럽지 않습니다. 높은 우선순위 번호 값(예: 60)을 지닌 ebuild 저장소의 이빌드는 낮은 우선순위(예: 50)를 가진 ebuild 저장소의 이빌드보다 우선합니다.

It is possible to instruct Portage to install a package from a specific ebuild repository with the :: version specifier (can be used for different emerge instructions, e.g. uninstalling a package through --depclean):

root #emerge --ask category/atom::ebuild repository-name

See the repository management section to see how to list repositories configured for portage with their respective priorities.

Repository synchronization

Ebuild repositories should be synchronized, so that the local mirrors will reflect a recent state of the repositories. This is necessary to be able to keep the system up to date, and install current software.

Regularly synchronizing with the Gentoo repository and updating the system in this way is important, to ensure that all the latest security updates are installed, and that the local system does not get too out of sync with the Gentoo repository, as this can make upgrades complicated if things have moved too far on in the repository.
Synchronize and update between daily or weekly to keep a Gentoo Linux installation running smoothly with the latest security updates. Waiting more than a few weeks to update may make things a little more complicated when the update is attempted. Please don't synchronize more than once daily, to avoid strain on the servers.
If local repositories are not very up to date, synchronize the repositories and update the system, before installing packages.

동기화(포티지 프로젝트)en게시글과 man 1 emaint를 참고하십시오.

user $emaint --help
usage: usage: emaint [options] COMMAND
The emaint program provides an interface to system health checks
and maintenance. See the emaint(1) man page for additional
information about the following commands:
  all            Perform all supported commands
  binhost        Scan and generate metadata indexes for binary packages.
  cleanconfmem   Check and clean the config tracker list for uninstalled packages.
  cleanresume    Discard emerge --resume merge lists
  logs           Check and clean old logs in the PORTAGE_LOGDIR.
  merges         Scan for failed merges and fix them.
  movebin        Perform package move updates for binary packages
  moveinst       Perform package move updates for installed and binary packages.
  sync           Check repos.conf settings and sync repositories.
  world          Check and fix problems in the world file.
optional arguments:
  -h, --help            show this help message and exit
  -c, --check           Check for problems (a default option for most modules)
  -f, --fix             Attempt to fix problems (a default option for most modules)
  --version             show program's version number and exit
  -C, --clean           Cleans out logs more than 7 days old (cleanlogs only) module-options: -t, -p
  -t NUM, --time NUM    (cleanlogs only): -t, --time Delete logs older than NUM of days
  -p, --pretend         (cleanlogs only): -p, --pretend Output logs that would be deleted
  -P, --purge           Removes the list of previously failed merges. WARNING: Only use this option if you plan on manually fixing them or do not want them re-installed.
  -y, --yes             (merges submodule only): Do not prompt for emerge invocations
  -r REPO, --repo REPO  (sync module only): -r, --repo Sync the specified repo
  -A, --allrepos        (sync module only): -A, --allrepos Sync all repos that have a sync-url defined
  -a, --auto            (sync module only): -a, --auto Sync auto-sync enabled repos only
  --sync-submodule {glsa,news,profiles}
                        (sync module only): Restrict sync to the specified submodule(s)

To sync all repositories for which auto-sync=true is set, run emaint sync with the --auto switch (-a for short). This is usually the command that should be run regularly, before system updates and package installation (and is equivalent to using the old emerge --sync command):

root #emaint sync --auto

To sync the foo repository (irrespective of the foo auto-sync setting):

root #emaint sync --repo foo

To sync all repositories with a valid sync-type and sync-url defined (ignoring auto-sync settings):

root #emaint sync --allrepos
For any repositories that should not be synced when running emaint sync --auto, auto-sync = no must be set in the appropriate file in /etc/portage/repos.conf, due to the default being auto-sync = true.

eix-synceix-update를 연달아 실행할 emerge --sync를 시작(emaint sync --auto 시작)하는 래퍼입니다. 더 자세한 내용은 Eix 글과 man 1 eix를 참고하십시오.

The emerge-webrsync tool can be used to download and install the daily Gentoo Repository rsync snapshot, to help with firewall restrictions, or to speed up the first synchronization, for example.

See man emaint for information on how to use the portage synchronization commands. See the Portage project sync article about migrating to the new modular sync system from Portage version 2.2.16, it contains important information, notably for users of eix-sync, esync -l, and emerge --sync .

모범 사례

캐시 만들기

큰 ebuild 저장소를 설치하면, 포티지에서 의존성 확인과 같은 작업을 처리하는데 오랜 시간이 걸릴 수 있습니다. 보통 ebuild 저장소에서 메타데이터 캐시를 보유하고 있지 않기 때문입니다.

ebuild 저장소를 동기화 한 후 emerge --regen 을 실행하여 로컬 메타데이터 캐시를 만들어야합니다:

root #layman -S
root #( ulimit -n 4096 && emerge --regen )

emerge --regen 작업은 오랜 시간이 걸리니 주의하십시오. rsync 사용자(대부분의 포티지 사용자)라면 서버측 캐시를 활용하여 rsync 업데이트를 수행하므로 추천하지 않습니다. rsync 사용자는 간단하게 emerge --sync 명령(또는 eix-sync)을 실행하여 캐시를 다시 만들면 됩니다. 대규모 ebuild 저장소 사용자에 한해서만 emerge --regen 을 시도하시면 되겠습니다.

안전하지 않은 ebuild 저장소가리기

알 수 없는 저질의 대규모 ebuild 저장소를 활용한다면 전체 ebuild 저장소에 영구 마스크를 지정하는 것이 좋은 방법입니다.

파일 /etc/portage/package.maskebuild 저장소의 모든 꾸러미에 마스크 설정
*/*::ebuild repository-name

Then add the specific package(s) from the repository-foobar overlay so that they will be available visible to Portage for installation:

파일 /etc/portage/package.unmaskebuild 저장소의 별도 꾸러미 마스크 해제
foo/bar::ebuild repository-name

그 다음 설치할 꾸러미의 마스크를 해제하십시오.

추가 참조

외부 자료