Handbook:Parts/Working/Portage/ko

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Working/Portage and the translation is 54% complete.
Outdated translations are marked like this.

포티지는 아마도 프로그램 관리에 있어서 가장 주목할만한 혁신 요소가 아닐까 싶습니다. 상당한 유연성과 방대한 기능들로 갖춰진 포티지는 자주 볼 수 있는 최고의 리눅스용 프로그램 관리 도구입니다.

포티지는 온전히 파이썬en배시en로 작성했기에 사용자들에게 완전히 두 스크립트 언어로 보입니다.

대부분의 사용자들은 emerge 도구로 포티지를 다룹니다. 이 장의 내용은 emerge 맨 페이지에서 볼 수 있는 정보를 베끼지 않았습니다. emerge 옵션의 전체 설명은 man 페이지를 참조하십시오:

user $man emerge

젠투 저장소

이빌드

꾸러미에 대해 이야기할 때면, 젠투 저장소에서 젠투 사용자들이 사용할 수 있는 프로그램의 제목을 의미합니다. 이 저장소는 포티지가 프로그램을 관리(설치, 검색, 요청 등)하기 위해 필요로 하는 모든 정보가 들어간 ebuild 파일의 모음입니다. 이 ebulid 파일은 기본적으로 /usr/portage 안에 있습니다.

여러분이 관심있는 프로그램 제목에 대해 어떤 동작을 요청할 때마다 시스템의 기반 요소로 ebuild를 사용합니다. 때문에 시스템의 ebuild를 주기적으로 갱신하여 포티지가 새 프로그램과 보안 갱신 등을 알리는 동작은 매우 중요합니다.

젠투 저장소 업데이트

보통 젠투 저장소는 빠른 증분 파일 전송 유틸리티 rsync로 업데이트합니다. emerge 명령을 rsync 프론트엔드로 제공하는 만큼 포티지 트리 업데이트는 상당히 간단합니다.

root #emerge --sync

방화벽 제한때문에 rsync를 사용할 수 없어도, 매일 만드는 스냅샷으로 젠투 저장소를 업데이트할 수 있습니다. emerge-websync 도구는 시스템에 최신 스냅샷을 가져오고 설치합니다.

root #emerge-webrsync

프로그램 관리

프로그램 검색

프로그램을 젠투 저장소에서 검색하는 방법에는 여러가지가 있습니다. 그중 한가지는 emerge로 찾는 방법입니다. 기본적으로 emerge --search가 제시한 단어에 일치하는 이름을 가진 꾸러미의 이름을 반환합니다.

예를 들어 "pdf"라는 이름을 가진 모든 꾸러미를 검색하려면:

user $emerge --search pdf

이와 마찬가지로 설명에서 검색하려면 --searchdesc (또는 -S) 스위치를 사용하십시오.

user $emerge --searchdesc pdf

많은 정보를 되돌려주는 출력 내용을 살펴보십시오. 확실히 이름표를 붙여놓았기 때문에 의미를 찾아보기 위해 그 이상 들어가지 않겠습니다:

코드 검색 명령 출력 예제
*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

프로그램 설치

원하는 프로그램 이름을 찾았다면 emerge 명령으로 프로그램을 쉽게 설치할 수 있습니다. 예를 들어 gnumetric을 설치하려면:

root #emerge --ask app-office/gnumeric

수많은 프로그램이 서로 의존관계가 있기 때문에 어떤 프로그램 꾸러미의 설치를 시도할 때, 이처럼 수많은 의존요소를 설치합니다. 포티지가 의존요소를 잘 관리하니 걱정하지 않으셔도 됩니다. 여러분이 어떤 꾸러미의 설치를 요청할 때 포티지가 설치할 꾸러미를 살펴보려면 --pretend 스위치를 덧붙이십시오. 예를 들자면:

root #emerge --pretend gnumeric

To do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:

root #emerge --ask gnumeric

꾸러미를 설치하는 동안, 포티지는 (필요하다면) 인터넷에서 필요한 소스 코드를 내려받고 기본적으로 /usr/portage/distfiles에 저장합니다. 그 다음 압축을 풀고 컴파일하고 꾸러미를 설치합니다. 포티지로 꾸러미를 설치하지 않고 소스코드를 다운로드만 하려면 emerge명령에 --fetchonly를 덧붙이십시오:

root #emerge --fetchonly gnumeric

설치한 꾸러미의 문서 찾기

대부분의 꾸러미는 문서가 딸려옵니다. 때로는, doc USE 플래그가 꾸러미의 문서를 설치할 지 말 지를 결정합니다. doc USE 플래그를 꾸러미에서 사용하는지 확인하려면 emerge -vp PACKAGENAME명령을 사용하십시오.

root #emerge -vp media-libs/alsa-lib
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

doc USE 플래그를 활성화하는 가장 좋은 방법은 /etc/portage/package.use에서 꾸러미마다 활성화하여 여러분이 얻고자 하는 해당 꾸러미의 문서를 가져오는 것입니다. 더 많은 내용을 보고자 한다면 USE 플래그장을 읽어보십시오.

꾸러미를 설치하고 나면 꾸러미에 대한 문서는 보통 /usr/share/doc 디렉터리의 꾸러미 이름이 달린 하위 디렉터리에서 찾을 수 있습니다:

user $ls -l /usr/share/doc/alsa-lib-1.1.3
total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

equery--filter 옵션을 활용하면 설치한 문서 파일 목록을 볼 수 있습니다. equery는 포티지 데이터베이스에 정보를 요청할 때 사용하며, app-portage/gentoolkit 꾸러미에 들어있습니다:

user $equery files --filter=doc alsa-lib
 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

--filter 옵션은 여러가지 형식을 지닌 파일의 설치 위치를 볼 때 다른 규칙을 부여할 때 사용합니다. 추가 기능은 equery 맨 페이지, man 1 equery에서 보실 수 있습니다.

프로그램 제거

프로그램 꾸러미를 시스템에서 제거하려면 emerge --unmerge를 사용하십시오. 설치 이후 바뀐 프로그램의 설정 파일을 제외하고 여러분의 시스템에서 꾸러미로부터 설치한 모든 파일을 제거하도록 포티지에 알립니다. 설정 파일을 남겨서 꾸러미를 다시 설치한다면 꾸러미를 계속 다룰 수 있습니다.

root #emerge --unmerge gnumeric

시스템에서 꾸러미를 제거할 때, 프로그램을 설치했을 때 자동으로 설치한 꾸러미의 의존 요소는 그대로 남습니다. 제거할 수 있는 모든 의존요소를 포티지가 찾도록 하려면 emerge의 --depclean 기능을 사용하십시오. 이 내용은 나중에 문서에서 다루겠습니다.

시스템 업데이트

시스템의 완벽한 모양새를 유지하(고 최신 보안 갱신 요소를 설치하도록 알림을 받지 않으)려면 시스템을 주기적으로 갱신해야합니다. 여러분이 처음 젠투 저장소를 새로 고칠 때 젠투 저장소의 이빌드만 확인합니다. 젠투 저장소를 업데이트하면, emerge --update @world로 시스템을 업데이트할 수 있습니다. 다음 예제에서는 --ask 스위치를 사용하여 업그레이드할 꾸러미의 목록을 표시하고 계속 할 것인지 물을 것을 포티지에 요청합니다.

포티지는 여러분이 설치한 프로그램의 최신 버전을 찾습니다. 그러나 이는 여러분이 확실히 설치한 프로그램의 버전만을 확인합니다 (프로그램의 목록은 /var/lib/portage/world에 있습니다). 이 절차는 의존성까지 철저히 확인하진 않습니다. 의존 요소까지 갱신하려면 --deep 옵션을 덧붙이십시오.

root #emerge --update --deep @world

시스템의 USE 설정을 바꾸었다면, 그에 따라 --newuse를 추가하는것이 좋습니다. 포티지는 플래그의 변경으로 새 꾸러미의 설치 또는 존재하는 꾸러미의 재 컴파일이 필요한지를 검증합니다.

root #emerge --update --deep --with-bdeps=y --newuse @world

메타꾸러미

젠투 저장소에서 어떤 꾸러미는 실제 내용을 포함하지는 않지만 꾸러미 모음을 설치하는데 사용합니다. 예를 들어 kde-apps/kde-meta 꾸러미는 의존요소로서의 다양한 KDE 관련 꾸러미를 시스템에 가져와서 완전한 KDE 환경으로 설치합니다.

이런 꾸러미를 시스템에서 제거할 때 이 꾸러미에 대해 emerge --unmerge를 실행하면 시스템에 남아있던 의존 효과가 더 이상 남지 않습니다.

포티지는 또한 버려진 의존성을 잘 제거하는 기능을 갖추고 있지만, 프로그램의 가용성은 동적으로 바뀌므로, 우선 USE 플래그를 바꾸었을 때 새로 바뀐 내용을 포함하여 전체 시스템을 업데이트 하는것이 중요합니다. 이 과정을 수행하고 나면 emerge --depclean을 실행하여 버려진 의존성을 제거할 수 있습니다. 포티지에 최근 추가한 기능이긴 하지만, 이 절차가 끝나면, 더이상 필요하지 않아 방금 삭제한 프로그램에 동적으로 연결한 프로그램을 다시 빌드해야합니다.

이 모든 과정을 다음 3개의 명령으로 처리합니다:

root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuild

라이선스

포티지 버전 2.1.7부터 라이선스를 기반으로 하여 프로그램 설치를 수락 혹은 거절할 수 있습니다. 트리상의 모든 꾸러미는 이빌드에 LICENSE 목록이 들어있습니다. emerge --search PACKAGENAME을 실행하면 꾸러미의 라이선스를 알려줍니다.

중요
{{{1}}}

기본적으로 포티지는 모든 라이선스를 허용하지만, 읽기를 요구하고 동의서에 동의여부를 확인해야 하는 최종 사용자 사용허가서(EULA)는 제외합니다.

허용할 라이선스를 제어하는 변수는 /etc/portage/make.conf 파일에 설정할 수 있는 ACCEPT_LICENSE 입니다. 다음 예제에서는 기본값을 나타냅니다:

파일 /etc/portage/make.confACCEPT_LICENSE 기본 설정
ACCEPT_LICENSE="* -@EULA"

이 설정을 통해 설치 과정상 EULA의 내용을 승인하려 직접 확인해야 하는 프로그램은 설치할 수 없습니다. EULA가 없는 꾸러미를 설치할 수 있습니다.

/etc/portage/make.conf에 전체적으로 ACCEPT_LICENSE를 설정하거나 각 꾸러미를 기반으로 /etc/package/package.license 파일에 지정할 수 있습니다.

예를 들어 www-client/google-chrome 꾸러미의 google-chrome 라이선스를 허용하려면, /etc/portage/package.license 파일에 다음을 추가하십시오:

파일 /etc/portage/package.licensegoogle-chrome 꾸러미에 google-chrome 라이선스 허용
www-client/google-chrome google-chrome

이 설정은 www-client/google-chrome 꾸러미 설치를 허용하지만, www-plugins/chrome-binary-plugins 꾸러미는 동일한 라이선스가 걸려있다 하더라도 설치를 못하도록 막습니다.

Or to allow the often-needed sys-kernel/linux-firmware:

파일 /etc/portage/package.licenseAccepting the licenses for the linux-firmware package
# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
중요
라이선스는 /usr/portage/license 디렉터리에 저장하며 라이선스 그룹은 /usr/portage/profiles/license_groups 파일에 저장합니다. 대문자로 이루어진 요소들 중 첫번째 항목은 라이선스 그룹의 이름이며, 모든 항목의 다음에는 각각의 라이선스를 의미합니다.

ACCEPT_LICENSE 변수에 정의한 라이선스 그룹은 @기호가 붙습니다. 일반적으로 요청하는 설정은 자유 소프트웨어 및 자유 문서의 설치만 허용하는 설정입니다. 이렇게 하려면 현재 허용하는 라이선스(-*)를 제거하고 다음과 같이 자유 그룹에 속한 라이선스만 허용하십시오:

파일 /etc/portage/make.conf자유 소프트웨어 및 자유 문서 라이선스만 동의
ACCEPT_LICENSE="-* @FREE"

Note that this setting will also accept non-free software and documentation.

포티지에서 불평할 때

용어

우리가 이전에 언급한대로라면, 포티지는 굉장히 강력하며 다른 프로그램 관리도구에서 빠진 수많은 기능을 지원한다고 했습니다. 이러한 점을 이해하기 위해, 더 자세히는 말고 적당한 선에서 포티지의 일부 모양새를 설명하도록 하겠습니다.

포티지에서 단일 꾸러미의 각기 다른버전이 시스템에 공존할 수 있습니다. 다른 배포판에서는 버전에 이름을 같이 붙이려 (예를 들자면 freetype과 freetype2와 같이) 하지만, 포티지는 SLOT이라는 용어를 사용합니다. ebuild는 이 버전에 대해 각각의 SLOT을 선언합니다. 제각각의 슬롯이 부여된 ebuild는 시스템에 공존할 수 있습니다. 예를 들어 freetype 꾸러미는 ebuild에 SLOT="1"과 SLOT="2"가 있습니다.

동일한 기능을 가지고 있으나 다른 방식으로 구현한 꾸러미도 있습니다. metalogd, sysklogd, syslog-ng 같은 경우는 모두 시스템 로거입니다. "시스템 로거" 기능에 따른 프로그램이지, 의존할 수 있는 프로그램은 아닙니다. 예를 들어, 다른 시스템 로거로서 metalogd는 바람직한 선택중 하나입니다. 포티지에서는 가상 요소를 허용합니다. 각 시스템 로거는 virtual 분류 항목의 logger 가상 꾸러미에 "배타적"인 로깅 서비스 의존성으로 참조하므로 이 프로그램은 virtual/logger 꾸러미에 의존할 수 있습니다. 가상 꾸러미를 설치하면, 로깅 꾸러미를 이미 설치하지 않았다면 (이 경우 가상 꾸러미를 고려함) 꾸러미에서 언급한 첫 로깅 꾸러미를 끌어옵니다.

젠투 저장소에 있는 프로그램은 다른 브랜치에 둘 수 있습니다. 기본적으로 시스템에서는 젠투에서 안정적인 꾸러미로 간주하는 꾸러미만 받아들입니다. 대부분의 새 프로그램 제목을 제출하면 시험 브랜치에 추가하며, 안정화 상태로 표시하기 전에 수많은 시험 과정이 필요함을 의미합니다. 젠투 저장소에 이 프로그램에 대한 이빌드가 존재하지만, 포티지에서 안정 브랜치에 올려놓기 전에는 업데이트하지 않습니다.

일부 프로그램은 일부 아키텍처에서만 쓸 수 있습니다. 또는 다른 아키텍처에서 동작하지 않거나, 시험이 더 필요하거나 다른 아키텍처에서 꾸러미가 동작하는지 젠투 저장소에 제출한 프로그램을 개발자가 시험할 수 없기도 합니다.

각각의 젠투 설치 과정은 시스템이 제 기능을 수행하는데 필요한 꾸러미 목록과 같은 여러 정보로 이루어진 프로파일을 충실히 따릅니다.

차단 꾸러미

코드 차단한 꾸러미에 대한 포티지 경고(--pretend 옵션 사용)
[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
  • Error: The above package list contains packages which cannot be
* installed at the same time on the same system.

(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by

   x11-wm/i3

Ebuild에는 의존성에 대해 포티지에 알려줄 특정 내용을 포함하고 있습니다. 이들 중에 두가지 가능한 의존성이 있습니다. 하나는 빌드 의존성에 대해 선언한 DEPEND 변수이며, 다른 하나는 실행시간 의존성에 대해 선언한 RDEPEND 변수입니다. 이들 의존성 중 하나가 호환되지 않는 꾸러미나 가상요소를 분명하게 지목했다면 실행시 막아버립니다.

포티지의 최근 버전은 사용자가 따로 설정하지 않아도 별로 중요하지 않은 차단 같은건 충분히 알아서 잘 처리합니다만 경우에 따라서는 아래에 설명한대로 직접 고쳐야 할 때도 있습니다.

차단 상황을 고치려면, 꾸러미를 설치하지 않거나 차단을 유발하는 꾸러미를 먼저 제거하는 방법 둘 중 하나를 정할 수 있습니다. 주어진 예제에서는, postfix를 설치하지 않거나 ssmtp를 먼저 제거하는 방법을 선택할 수 있습니다.

<media-video/mplayer-1.0_rc1-r2와 같이 특정 요소에 대한 차단 꾸러미를 볼 수도 있습니다. 이런 경우에는 차단 꾸러미의 최신 버전으로 업데이트 하면 차단이 풀립니다.

아직 설치하지 못한 서로 차단하는 두 꾸러미들에게도 가능한 방법이 있습니다. 이 드문 경우에는 왜 두 꾸러미를 설치해야 하는지를 알아야 합니다. 대부분의 경우 둘 중 하나만 설치할 수 있습니다. 둘 다 설치해야 한다면, 젠투 버그 추적 시스템에 버그를 제출하십시오.

가려놓은 꾸러미

코드 가려놓은 꾸러미에 대한 포티지 경고
!!! all ebuilds that could satisfy "bootsplash" have been masked.
코드 가려놓은 꾸러미에 대한 포티지 경고 - 이유
!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

시스템에서 사용할 수 없는 꾸러미를 설치하려 할 때 이런 가려짐 오류가 나타납니다. 시스템에서 쓸 수 있는 다른 프로그램을 설치하려고 하거나 꾸러미가 쓸 수 있는 상태가 될 때까지 기다리셔야 합니다. 꾸러미를 가린 이유는 얼마든지 있습니다:

가려놓은 이유 설명
~arch 키워드 프로그램을 안정 브랜치에 올려놓기에는 충분히 시험하지 않았습니다. 며칠 또는 몇주 기다린 후 다시 받아보십시오.
-arch 키워드 또는 -* 키워드 해당 프로그램은 사용자 여러분이 사용하는 머신에서 기계 명령 체계가 달라 동작하지 않습니다. 해당 꾸러미가 동작한다면, 버그질라 웹사이트에 문제점을 보고하십시오.
키워드 누락 해당 프로그램은 사용자 여러분이 사용하는 머신에서 테스트하지 않았습니다. 아키텍처 이식팀에 해당 꾸러미를 테스트하도록 요청하거나 직접 테스트하여 버그질라 웹 사이트에 발견한 문제점을 보고하십시오.
package.mask 이 꾸러미는 깨졌거나, 불안정하거나, 무엇인가 잘못되어 사용하지 말라는 의미에서 표시해둔 항목입니다.
profile 현재 프로파일에 알맞지 않음을 확인한 꾸러미입니다. 이 꾸러미를 설치하면 시스템을 깨먹거나 현재 사용하는 프로파일과 호환되지 않을 수 있습니다.
license 꾸러미의 라이선스가 ACCEPT_LICENSE 변수에 설정한 값과 호환되지 않습니다. 라이선스를 허용하거나 /etc/portage/make.conf 또는 /etc/portage/package.license 파일에 올바른 라이선스를 설정하십시오

USE 플래그 변경의 필요성

코드 USE 플래그 변경 요구에 대한 포티지 경고
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

--autounmask를 설정하지 않았을 때 다음과 같은 오류메시지가 뜰 때도 있습니다.

코드 USE 플래그 변경 요구에 대한 포티지 오류
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

다른 꾸러미에만 의존하지 않는 꾸러미를 설치하려 할 때 이런 경고나 오류가 발생하지만, 어떤 USE 플래그 (또는 USE 플래그 모음)로 꾸러미를 반드시 빌드해야 할 필요가 있을때에도 그렇습니다. 주어진 예제에서는 app-text/feelings 꾸러미가 USE="test" 로 빌드해야겠지만 시스템에 이 플래그를 설정하지 않은 상황입니다.

이 문제를 해결하려면 /etc/portage/make.conf의 전역 USE 플래그에 요구하는 USE 플래그를 추가하거나 /etc/portage/package.use에 지정 꾸러미에 대한 플래그를 설정하십시오.

빠진 의존성

코드 빠진 의존요소에 대한 포티지 경고
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

시스템에 존재하지 않는 다른 꾸러미에 의존하여 프로그램을 설치하려고 했습니다. 이미 알려진 문제라면 버그질라를 확인해주시고, 없다면 보고해 주십시오. 브랜치를 뒤섞어 엎어놓지 않는한 이 일은 발생하지 않겠지만, 그렇기 때문에 이런 현상은 버그입니다.

애매모호한 이빌드 이름

코드 애매모호한 이빌드 이름에 대한 포티지 경고
[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

설치하려는 프로그램이 하나 이상의 꾸러미와 관련된 이름을 지니고 있습니다. 이럴 경우 카테고리 이름을 같이 넣어줘야 합니다. 포티지는 선택할 수 있는 일치 항목을 알려줍니다.

순환 의존성

코드 순환 의존성에 대한 포티지 경고
!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

설치하려는 두가지 (이상) 의 꾸러미가 서로 의존성을 가져 설치할 수 없습니다. 거의 젠투 저장소의 버그일 수 있습니다. 조금 지난 후 다시 트리를 동기화 한 다음 재시도하십시오. 또한 이미 알려진 문제라면 버그질라를 확인할 수 있는데, 없다면 보고하십시오.

가져오기 실패

코드 가져오기 실패에 대한 포티지 경고
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

포티지가 다른 프로그램의 (쓸 수 있는 경우) 설치를 계속하려고 할 때 주어진 프로그램에 대한 소스코드를 내려받을 수 없습니다. 이 문제는 올바르게 동기화 하던 미러가 어긋났다거나 ebuild가 잘못된 위치를 가리켰기 때문에 발생할 수 있습니다. 어떤 이유 때문에 소스 코드가 있는 서버가 먹통이 되었을 수도 있습니다.

문제가 여전히 생기면 몇시간 후 다시 시도하십시오.

시스템 프로파일 보호

코드 프로파일에서 보호한 꾸러미에 대한 포티지 경고
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

시스템의 핵심 꾸러미 제거를 요청했습니다. 이런 메시지가 뜨면 프로파일에서 필요하다고 적어넣은 꾸러미이기 때문에 시스템에서 제거해서는 안되겠습니다.

다이제스트 검증 실패

코드 다이제스트 검증 실패
>>> checking ebuild checksums
!!! Digest verification failed:

이는 젠투 저장소에 뭔가 문제가 있다는 이야기입니다. 보통 젠투 이빌드 저장소에 이빌드를 제출할 때 실수하여 발생하는 문제입니다.

다이제스트 검증에 실패하면 꾸러미의 다이제스트를 다시 만들지 마십시오. ebuild foo manifest를 실행해도 문제는 고쳐지지 않습니다. 이렇게하면 일을 더 꼬이게 할 수 있습니다.

대신 저장소 상태가 바로 잡힐 때까지 한두시간 정도 기다려보십시오. 올바르지 않은 방법으로 오류가 나타났을 수도 있는 것이지만, rsync 미러가 서서히 자리를 잡는데 시간이 좀 걸릴 수가 있습니다. 기다리는 동안에 버그질라를 확인해보시고 누군가가 이 문제를 보고했는지 찾아보거나 #gentoo (webchat)에서 질문하십시오. 만약 내용이 없다면 가서 깨진 이빌드의 문제를 알려주십시오.

문제점을 고치고 나면, 젠투 이빌드 저장소를 다시 동기화 하여 수정한 다이제스트를 받으십시오.

중요
젠투 이빌드 저장소를 하루에 한번 이상 동기화하지 않도록 주의하십시오. 공식 젠투 네티켓 정책(emerge --sync 실행시)에서는, 자주 동기화하는 사용자는 잠시동안 추가 동기화 과정에서 막습니다. 이 정책을 따르지 않고 반복적으로 위반하는 남용 사용자는 완전히 추방할 수 있습니다. 분명 필요한 일이 아니라면 24시간 주기로 동기화 하여 재동기화 동작으로 하여금 젠투 rsync 미러에 부하를 주지 않도록 하는게 좋습니다.