젠투 리눅스 ppc 핸드북: 젠투 다루기

This page is a translated version of the page Handbook:PPC/Full/Working and the translation is 100% complete.

포티지로 오신것을 환영함

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

포티지는 온전히 파이썬^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 미러에 부하를 주지 않도록 하는게 좋습니다.

← 마무리 처음 USE 플래그 →

USE 플래그란

USE 플래그 개념

젠투(또는 기타 배포판이나 어떤 운영체제든)를 설치할 때, 사용자는 다룰 환경에 따라 몇가지 선택을 하고 싶어합니다. 서버에 대한 설정은 워크스테이션에 대한 설정과 다릅니다. 게임용 워크스테이션은 3D 렌더링 워크스테이션과 다릅니다.

꾸러미를 설치할 때만 그런게 아니며 각각의 꾸러미에서 어떤 기능을 선택해야 하느냐를 따질때도 마찬가지입니다. OpenGL이 필요하지 않은데, 왜 대부분 꾸러미에서의 OpenGL의 설치 및 관리, 빌드 지원이 우릴 귀찮게 할까요? KDE를 쓰고 싶지 않은데, 왜 굳이 없어도 완벽하게 돌아가는 KDE 지원이 꾸러미 컴파일 과정에서 귀찮게 할까요?

사용자가 어떤 꾸러미를 설치하고 활성화 해야 할 지 말지 결정하는 일련의 과정을 돕기 위해, 젠투에서는 사용자가 쉬운 방법으로 환경을 지정하길 원했습니다. 이런 일련의 사고를 통해 사용자가 정말로 원하는 바를 결정하도록 사용자를 끌어넣었고, 쓸만한 결정을 처리하도록 포티지의 처리 과정을 쉽게 만들었습니다.

USE 플래그 정의

USE 플래그를 입력하십시오. 각각의 플래그는 지원 기능과 각각의 개념에 대한 의존성 정보를 포함하는 키워드입니다. 어떤 USE 플래그를 지정하면, 포티지에서는 선택한 키워드에 대해 사용자가 어떤 지원 기능을 원하는지 알아차립니다. 물론 이 과정에서 꾸러미에 대한 의존성 정보로 바꾸기도 합니다.

몇가지 특정 예를 살펴보겠습니다: kde 키워드가 있습니다. 이 키워드를 USE 변수에 넣지 않으면, 모든 꾸러미는 KDE 지원 없이 선택적인 KDE 지원을 컴파일합니다. 선택적 KDE 의존성을 지닌 모든 꾸러미는 KDE 라이브러리를 (의존 요소로) 설치하지 않고 설치합니다. kde 키워드를 지정하면 이 꾸러미에 KDE 지원 기능을 함께 컴파일하며 KDE 라이브러리를 의존 요소로 설치합니다.

When the kde flag is set to enabled, then those packages will be compiled with KDE support, and the KDE libraries will be installed as dependency.

올바르게 키워드를 지정하면 사용자의 요구에 맞춰 시스템의 모양새가 갖춰집니다.

USE 플래그 사용

영구 USE 플래그 선언

앞에서 이야기한 바와 같이, 모든 USE 플래그는 USE 변수에 선언합니다. 사용자가 USE 플래그를 쉽게 검색하고 고를 수 있도록 하기 위해 기본 USE 설정을 제공합니다. 이 설정은 젠투 사용자가 보통 사용한다고 간주하는 USE 플래그의 모음입니다. 이 기본 설정은 선택한 프로파일의 일부인 make.defaults 파일에 선언했습니다.

시스템이 살펴보는 프로파일은 /etc/portage/make.profile이 가리킵니다. 각각의 프로파일은 다른 프로파일의 상위에서 동작하며 최종 결과는 모든 프로파일의 합입니다. 최상위 프로파일은 베이스 프로파일(/usr/portage/profiles/base)입니다.

현재 활성화 한 (전체) USE 플래그를 보려면 emerge --info를 사용하십시오:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

보시는 바와 같이, 변수에 수많은 키워드가 있습니다. 개인적인 용도로 USE 변수를 새로 뜯어고칠 목적으로 make.defaults 파일의 내용을 어떤 부분이든 바꾸지 마십시오. 이 파일의 내용을 바꾸면 젠투 저장소를 업데이트했을때 되돌릴 수 없습니다!

기본 값을 바꾸려면 USE 변수에서 키워드를 추가하거나 제거하십시오. /etc/portage/make.conf에서 전역 범위의 USE 변수 값을 지정하시면 됩니다. 이 변수에서 필요한 추가 USE 플래그를 추가하거나 더 이상 필요하지 않은 USE 플래그를 제거할 수 있습니다. 플래그 제거는 키워드 앞에 음수 부호(-)를 붙이시면 됩니다.

KDE와 Qt 지원을 제거하고 LDAP 지원을 추가한다면, /etc/portage/make.conf에서 USE 값을 다음처럼 지정할 수 있습니다:

파일 /etc/portage/make.confmake.conf에서 USE 플래그 설정 업데이트

USE="-kde -qt4 -qt5 ldap"

개별 꾸러미당 USE 플래그 선언

때로는 시스템 전체가 아니라 특정 프로그램 하나 (또는 그 이상)의 USE 플래그 몇가지를 설정하고 싶을 때가 있습니다. 이럴 때는, /etc/portage/package.use 파일을 편집하십시오. package.use는 보통 파일이지만, 하위 경로에 파일이 들어간 디렉터리일 수도 있습니다. 아래 요령을 참고하고 man 5 portage 도움말에서 이 파일의 문법 정보를 참고하십시오. 다음 예제에서는 package.use가 단일 파일임을 가정합니다.

예를 들어 VLC 미디어 재생기 프로그램에 블루레이 지원만을 넣으려면:

파일 /etc/portage/package.useVLC 블루레이 지원 활성화

media-video/vlc bluray

요령
package.use가 이미 디렉터리(단일 파일 아님) 형태로 있다면, package.use/ 디렉터리 아래에 간단하게 파일을 만들어 USE 플래그를 부분적으로 설정할 수 있습니다. 어떤 파일 이름이든지간에 동작하지만 일관된 이름 형식을 갖추는게 좋습니다. 이름을 짓는 방식 중 하나로는 하위 파일 이름을 간단하게 꾸러미 이름으로 짓는 방식이 있습니다. 예를 들어 bluray USE 플래그를 media-video/vlc 꾸러미에만 지정할 경우 다음 명령을 실행하여 처리할 수 있습니다:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

이와 비슷하게 각각의 프로그램에 대해 USE 플래그를 분명히 비활성화할 수 있습니다. PHP에서 bzip2지원을 비활성화할 경우(하지만 make.conf의 USE 플래그 지정을 통해 다른 꾸러미에는 활성화할 경우):

파일 /etc/portage/package.usePHP에서 java지원 비활성화

dev-lang/php -bzip2

임시 USE 플래그 선언

잠깐동안 USE 플래그를 설정해야 할 때도 있습니다. /etc/portage/make.conf를 두 번 편집하는 대신(USE값 바꾸기를 했다가 취소) USE 변수를 환경 변수처럼 지정하면 됩니다. 입력한 명령에 대해서만 이 설정을 적용함을 기억하십시오. 프로그램을 다시 이머지하거나 업데이트(분명히 둘 다 하든지 시스템 업데이트의 일부로 처리하든지)하면 (임시로) 지정한 USE 플래그로 바꾸어놓은 상태를 되돌립니다.

다음 예제에서는 SeaMonkey를 설치하는 과정에서 USE 변수의 pulseaudio 플래그 값을 임시로 제거합니다:

root #USE="-pulseaudio" emerge www-client/seamonkey

우선 처리

물론 어떤 설정이 USE 설정에 우선하는가에 대한 우선 처리 방식이 있습니다. USE 설정에 대한 우선 처리는 우선 순위에 따릅니다(처음 항목은 우선순위가 낮음)

프로파일의 일부인 make.defaults 파일에서 지정한 기본 USE 설정
/etc/portage/make.conf의 사용자 지정 USE 설정
/etc/portage/package.use의 사용자 지정 USE 설정
환경 변수로 지정한 사용자 지정 USE 설정

포티지에서 본 최종 USE 설정을 보려면 emerge --info를 실행하십시오. 포티지에서 알고 있는 현재 지정 값을 지닌 모든 관련 변수(USE 변수 포함)를 보여줍니다.

root #emerge --info

전체 시스템에 새 USE 플래그 적용

USE 플래그 값을 바꾸고 나면 필요한 변경 사항을 반영하기 위해 시스템을 업데이트해야합니다. 업데이트를 진행하려면 emerge 명령에 --newuse 옵션을 사용하십시오.

root #emerge --update --deep --newuse @world

다음, 포티지의 depclean을 실행하여 "이전" 시스템에 이머지한 꾸러미 중, 새 USE 플래그 모음에서 사라진 조건부 의존성을 제거하십시오.

경고
emerge --depclean 명령 실행은 위험한 동작이며 조심스레 취급해야합니다. 필요한 꾸러미를 제거하는지 확인하려면 "오래된" 꾸러미 목록을 다시 한 번 살펴보십시오. 다음 예제에서는 실제로 꾸러미를 제거하지 않고 depclean할 꾸러미의 목록이 무엇인지 -p 스위치로 확인합니다.

root #emerge -p --depclean

depclean이 끝나면, revdep-rebuild를 실행하여 제거했을지도 모르는 꾸러미에서 제공하는 공유 객체에 동적으로 연결한 프로그램을 다시 빌드하십시오. revdep-rebuild는 app-portage/gentoolkit의 일부입니다. 이 꾸러미를 꼭 이머지하십시오.

root #revdep-rebuild

모든 과정을 끝나면 시스템에서는 새 USE 플래그를 사용합니다.

꾸러미별 USE 플래그

사용할 수 있는 USE 플래그 보기

seamonkey 예제를 보도록 하겠습니다. 어떤 USE 플래그를 살펴보고 있을까요? emerge 명령에 --pretend옵션과 --verbose옵션으로 확인해보겠습니다:

root #emerge --pretend --verbose www-client/seamonkey

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

emerge만 이 작업을 하는 도구가 아닙니다. 실제로 app-portage/gentoolkit 꾸러미에 있는 equery가 꾸러미 정보를 제공하기도 합니다.

root #emerge --ask app-portage/gentoolkit

이제 equery에 uses 매개변수를 붙여 각각의 꾸러미에서 사용하는 USE 플래그를 살펴보겠습니다. gnumeric 꾸러미의 내용을 살펴보면:

user $equery --nocolor uses =gnumeric-1.12.31

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-office/gnumeric-1.12.31:
 U I
 + + introspection            : Add support for GObject based introspection
 - - libgda                   : Enable database support through gnome-extra/libgda.
 - - perl                     : Enable perl plugin loader.
 + + python                   : Enable python plugin loader.
 + + python_targets_python2_7 : Build with Python 2.7

REQUIRED_USE 상태 충족

일부 이빌드에서는 제대로 동작하게 하려 일부 USE 플래그 조합을 요구하거나 막는 경우가 있습니다. 이런 경우 REQUIRED_USE 조건에 있는 여러 조건으로 표현합니다. 이 조건은 모든 기능과 의존성이 완벽한지 확인하며, 빌드를 성공시키고, 기대하던 동작이 가능하도록 합니다. 이 조건을 만나지 못하면 이머지에서는 문제를 해결하도록 경고하고 요구합니다.

예제	설명
`REQUIRED_USE="foo? ( bar )"`	`foo`를 설정했다면, `bar`를 설정해야 함.
`REQUIRED_USE="foo? ( !bar )"`	`foo`를 설정했다면, `bar` 는 설정하지 말아야 함.
`REQUIRED_USE="foo? ( \|\| ( bar baz ) )"`	`foo`를 설정했다면, `bar` 또는 `baz` 를 설정해야 함.
`REQUIRED_USE="^^ ( foo bar baz )"`	`foo`, `bar`, `baz` 중 하나만 설정해야 함.
`REQUIRED_USE="\|\| ( foo bar baz )"`	최소한 `foo`, `bar`, `baz` 중 하나는 설정해야 함.
`REQUIRED_USE="?? ( foo bar baz )"`	`foo`, `bar`, `baz` 중 하나만 설정할 수 있음.

← 포티지 소개 처음 포티지 기능 →

포티지 기능

포티지는 여러분의 더 나은 젠투 경험을 만들어줄 여러가지 추가 기능이 있습니다. 이 수많은 기능들은 성능, 신뢰성, 보안 등을 개선하기 위한 몇가지 프로그램 도구에 의지합니다.

이들 포티지 기능을 활성화 하거나 비활성화 하려면, 공백으로 구분한 여러 기능 키워드가 들어있는 /etc/portage/make.conf의 FEATURES 변수를 편집할 필요가 있습니다. 대부분의 경우 기능과 관련한 추가 도구를 설치해야 합니다.

여기에 언급한 포티지 지원 기능이 기능 전부를 의미하지는 않습니다. 전체적으로 간단히 살펴보려면 make.conf 맨 페이지를 참고하십시오:

user $man make.conf

FEATURES 변수에 어떤 값을 기본으로 지정했는지 보려면 emerge --info를 실행하여 FEATURES 변수를 찾아보거나 grep으로 출력 내용을 잡아내십시오:

user $emerge --info | grep ^FEATURES=

분산 컴파일

distcc 사용

distcc 프로그램은 네트워크 상에서 반드시 동일할 필요가 없는 많은 장비들로 분산 컴파일을 수행하는 프로그램입니다. distcc 클라이언트는 사용가능한 distcc 서버(distccd 실행)에 필요한 정보를 보내서 클라이언트에 대한 소스코드 일부를 컴파일 할 수 있게 합니다. 이 네트워크를 통해 컴파일 시간이 더 빨라집니다.

distcc에 대한 더 자세한 정보(와 젠투에서 동작하게 하는 방법)는 distcc 글에서 찾아 보실 수 있습니다.

distcc 설치

distcc에는 컴파일할 내용을 전달하는 컴퓨터의 작업을 감시하는 그래픽 감시 프로그램이 있습니다. USE=gnome 또는 USE=gtk를 설정하면 이 도구를 자동으로 설치합니다.

root #emerge --ask sys-devel/distcc

포티지 distcc 지원 활성화

distcc를 /etc/portage/make.conf의 FEATURES 변수에 추가하십시오. 다음, 여러분이 원하는대로 MAKEOPTS 변수를 편집하십시오. 알려진 지침대로라면 -jN의 N에 distccd를 실행하는 CPU의 갯수 + 1을 채워넣는 것입니다만, 단순히 지침일 뿐입니다.

이제 distcc-config를 실행하고 사용할 수 있는 distcc 서버의 목록을 입력하십시오. 간단한 예로, 사용할 수 있는 DistCC 서버가 192.168.1.102(현재 호스트), 192.168.1.103, 192.168.1.104(두개의 "원격" 호스트)라고 가정합니다.

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

마찬가지로 distccd 데몬 실행도 잊지 마십시오:

root #

rc-update add distccd default

root #/etc/init.d/distccd start

컴파일 객체 캐시

ccache 정보

ccache는 빠른 컴파일러 캐시입니다. 프로그램을 컴파일 할 때 중간 내용을 캐시해서 같은 프로그램을 언제 다시 컴파일 하든지 상관없이 컴파일 타임은 급격하게 줄입니다. ccache를 처음 실행할 때 보통 컴파일 할 때보다 훨씬 느립니다. 그 다음 다시 컴파일 할 때 더 빨라집니다. ccache는 같은 프로그램을 여러번 컴파일 할 때만 도움됩니다. 따라서 이는 대부분 프로그램 개발자들에게만 유용합니다.

ccache에 대한 더 많은 내용은 홈페이지^en를 방문해보십시오.

경고
ccache는 수많은 컴파일 실패를 유발하는 것으로 알려져 있습니다. ccache가 낡아빠진 코드 객체나 깨진 파일을 유지하여 꾸러미를 이머지하지 못하게 하기도 합니다. 만약 이런 일이 일어난다면(즉, "File not recognized: File truncated"와 같은 오류 메시지를 만났다면), 버그를 보고 하기 전에 ccache를 비활성화 한 상태(/etc/portage/make.conf에서 FEATURES="-ccache")에서 프로그램을 다시 컴파일 해보십시오. 개발작업을 하지 않는 한 ccache를 활성화하지 마십시오.

ccache 설치

ccache를 설치하려면 다음 명령을 실행하십시오:

root #emerge --ask dev-util/ccache

포티지 ccache 지원 활성화

/etc/portage/make.conf를 열고 FEATURES 변수의 아무 값 사이에 ccache값을 추가하십시오. FEATURES 변수가 없다면 새로 만드십시오. 다음 새 CCACHE_SIZE 변수를 추가하고, 2G로 설정하십시오:

파일 /etc/portage/make.conf포티지 ccache 지원 활성화

FEATURES="ccache"
CCACHE_SIZE="2G"

ccache 기능을 확인하려면 ccache에게 통계 데이터를 제공해달라고 요청하십시오. 포티지가 다른 ccache 홈 디렉터리를 사용하기 때문에 CCACHE_DIR 변수를 임시로 설정해야합니다:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

/var/tmp/ccache 위치는 포티지의 기본 ccache 홈 디렉터리 입니다. /etc/portage/make.conf의 CCACHE_DIR 변수 값을 설정하여 위치를 바꿀 수 있습니다.

ccache를 자체적으로 실행할 때, ${HOME}/.ccache 기본 위치를 사용하는데, 이것이 (포티지) ccache 통계를 요청할 때 CCACHE_DIR 변수를 설정해야 할 이유입니다.

포티지 외의 용도로 ccache 사용

비 포티지 컴파일을 목적으로 ccache를 사용하려면 PATH변수의 앞부분에 (/usr/bin 앞에) /usr/lib/ccache/bin을 추가하십시오. 사용자 홈 디렉터리에 있는 ~/.bash_profile을 편집하면 됩니다. ~/.bash_profile을 활용하는 방법이 PATH 변수를 정의하는 방법입니다.

파일 ~/.bash_profile다른 PATH 값 앞에 ccache 경로 추가

PATH="/usr/lib/ccache/bin:${PATH}"

바이너리 꾸러미 지원

미리 빌드한 꾸러미 만들기

포티지는 미리 빌드한 꾸러미의 설치를 지원합니다. 젠투가 자체적으로 미리 빌드한 꾸러미를 제공하는 것은 아니지만, 포티지에서 미리 빌드한 꾸러미를 완전히 인식할 수 있습니다.

미리 빌드한 꾸러미를 만들려면, 꾸러미가 이미 시스템에 설치되어 있는 경우 quickpkg를 사용하거나, emerge에 --buildpkg옵션 또는 --buildpkgonly옵션을 붙여서 사용하십시오.

여러분이 설치한 모든 단일 꾸러미에 대해 포티지로 미리 빌드한 꾸러미를 만들려면 FEATURES 변수에 buildpkg를 추가하십시오.

미리 빌드한 꾸러미를 만들기 위한 더 많은 지원은 catalyst로 받을 수 있습니다. catalyst에 대한 더 많은 정보를 보시려면 Catalyst 자주 묻는 질문^en을 읽어보십시오.

미리 빌드한 꾸러미 설치

비록 젠투에서 제공하는건 아니지만, 미리 빌드한 꾸러미를 저장한 중앙 저장소를 만들 수 있습니다. 이 저장소를 사용하려면 PORTAGE_BINHOST 변수를 통해 저장소를 포티지에서 인식하도록 해야합니다. 예를 들어, 미리 빌드한 꾸러미가 ftp://buildhost/gentoo 에 있다면:

파일 /etc/portage/make.confPORTAGE_BINHOST 위치 추가

PORTAGE_BINHOST="ftp://buildhost/gentoo"

미리 빌드한 꾸러미를 설치하려면, emerge 명령에 --usepkg옵션 다음에 --getbinpkg 옵션을 추가하십시오. 이 구성자는 후자가 emerge 에게 소스코드를 가져오고 컴파일 하기 전에 미리 빌드한 꾸러미의 설치를 시도해보라고 알리며, 앞서 정의한 서버에서 미리 빌드한 꾸러미를 내려받으라고 요청합니다.

미리 빌드한 꾸러미를 통해 gnumeric을 설치하려면:

root #emerge --usepkg --getbinpkg gnumeric

더 많은 emerge의 미리 빌드한 꾸러미 옵션은 emerge 맨 페이지에서 찾아보실 수 있습니다:

user $man emerge

미리 빌드한 꾸러미를 다른 곳으로 배포

미리 빌드한 꾸러미를 다른 사용자에게 배포한다면, 이 꾸러미 사용을 허락했는지 확인하십시오. 업스트림 꾸러미의 배포 조항을 확인하십시오. 예를 들어, GNU GPL 조항에 따라 꾸러미를 배포한다면, 소스코드를 바이너리와 함께 배포해야 합니다.

빌드한 바이너리를 배포할 수 없을 경우 ebuild에 RESTRICT 변수를 통해 bindist 제한을 걸 수 있습니다. 때로는 이 제한을 하나 이상의 USE 플래그에 넣을 수 있습니다.

기본적으로 포티지는 제한을 이유로 어떤 꾸러미도 가리지 않습니다. 이런 정책은 /etc/portage/make.conf에서 ACCEPT_RESTRICT 변수를 설정하여 시스템 전체적으로 바꿀 수 있습니다. 예를 들어 bindist 값을 가진 꾸러미를 가리려면 make.conf에 다음 줄을 추가하십시오:

파일 /etc/portage/make.conf배포 가능한 바이너리만 허용

ACCEPT_RESTRICT="* -bindist"

emerge 명령에 --accept-restrict 옵션을 적용하여ACCEPT_RESTRICT 변수를 중복 적용할 수 있습니다. 예를 들어, --accept-restrict=-bindist 옵션은 bindist 제약 조건으로 임시로 꾸러미를 가립니다.

꾸러미를 배포할 때 ACCEPT_LICENSE 변수 설정을 고려할 수 있습니다. 라이선스 항목을 참고하십시오.

중요
각 사용자는 꾸러미 라이선스 조항과 해당 국가의 법률을 전적으로 따를 의무가 있습니다. ebuild에서 설정한 메타데이터 변수(RESTRICT 또는 LICENSE)는 바이너리 배포를 허용하지 않을 경우 지침을 제공할 수 있지만, 포티지의 출력이나 젠투 개발자가 답변한 질문이 합법인 것은 아니며, 개별적인 경우에 이러한 보편 사항을 적용하면 안됩니다. 실제 거주지의 법률에 위배되는지 신중히 검토하십시오.

파일 가져오기

Verify distfiles

To re-verify the integrity and (potentially) re-download previously removed/corrupted distfiles for all currently installed packages, run:

root #emerge --ask --fetchonly --emptytree @world

← USE 플래그 처음 초기화 스크립트 시스템 →

중요
The contents of this page do not apply to users that chose a systemd profile in Choosing the right profile.

실행 레벨

시스템 부팅

시스템을 부팅하면 수많은 텍스트가 떠다닙니다. 더 자세히 들여다보면 여러분이 다시 부팅할 때마다 이 텍스트가 같은 내용이 항상 나오는 것을 보실 수 있습니다. 이 동작의 순서를 부트 시퀀스라고 하며, (더 혹은 덜) 정적으로 정의합니다.

먼저 부트로더는 CPU한테 커널을 실행하라고 알린 다음에 부트로더 설정에 지정되어 있는 커널 이미지를 메모리에 불러옵니다. 커널을 불러와서 실행한 후 모든 커널 관련 구조를 초기화하고 init 과정을 시작합니다.

이 프로세스는 (/etc/fstab에 지정한) 모든 파일 시스템을 마운트 했는지 사용할 준비가 되었는지를 확인합니다. 그 다음 시스템을 성공적으로 부팅하기 위해 필요한 서비스를 시작하려고 /etc/init.d의 수 많은 스크립트를 실행합니다.

마지막으로 모든 스크립트를 실행하고 나면, init 에서 터미널(대부분의 경우 Alt+F1, Alt+F2 키로 숨겨놓은 가상 콘솔입니다)을 활성화하고 agetty라고 하는 특별한 프로세스를 터미널에 붙입니다. 이 과정에서 로그인을 실행하여 터미널로 로그온을 할 수 있는지 확인합니다.

Initscripts

여기서 init는 /etc/init.d/에 있는 스크립트를 임의대로 실행하는 것이 아닙니다. 게다가 /etc/init.d/에 있는 모든 스크립트를 실행하는 것도 아니며 실행하라고 지시한 스크립트만 실행합니다. 이는 /etc/runlevels/를 확인하여 어떤 스크립트를 실행할 지 결정합니다.

먼저 init는 /etc/init.d/에서 /etc/runlevels/boot에 심볼릭 링크한 모든 스크립트를 실행합니다. 보통 철자순으로 스크립트를 실행하겠지만 어떤 스크립트의 경우 이들 스크립트를 실행하기 전에 다른 스크립트를 먼저 실행해야 한다고 시스템에 알려주는 의존성 정보를 가지고 있습니다.

/etc/runlevels/boot가 참조하는 스크립트를 실행하고 나면 init는 /etc/runlevels/default에 심볼릭 링크한 스크립트의 실행을 계속합니다. 다시 한 번 말씀드리지만, 어떤 스크립트를 먼저 실행할 지는 유효한 시작 순서를 제공하도록 순서를 바꾸는 의존성 정보를 가지고 있지 않는 한 철자순서를 사용하여 결정합니다. 후자는 왜 젠투리눅스 설치 과정에서 rc-update add sshd default의 default를 사용하는 지에 대한 답입니다.

init 동작 방식

물론 init 에서 모든 사항을 자체적으로 결정하지 못합니다. 어떤 동작을 취해야 할지 지시하는 설정 파일이 필요합니다. 이 설정 파일은 /etc/inittab입니다.

우리가 적은대로 부팅 순서를 기억한다면, 여러분이 기억하기로는 init에서 처음 하는 동작은 모든 파일 시스템의 마운트입니다. /etc/inittab의 다음 줄에 설정했습니다:

파일 /etc/inittab초기화 명령

si::sysinit:/sbin/rc sysinit

이 줄은 시스템을 초기화하는 /sbin/rc sysinit을 실행해야 한다고 init에 일러줍니다. /sbin/rc 스크립트는 초기화를 다루므로 init이 더 이상 진행하지 말도록 여러분이 알려야 합니다. -- 이는 시스템이 초기화 작업을 수행하도록 다른 프로세스에 일임합니다.

두번째로, init은 /etc/runlevels/boot에 심볼릭 링크를 걸어둔 모든 스크립트를 실행합니다. 이는 다음의 줄에서 설정했습니다:

파일 /etc/inittab부팅 명령 실행

rc::bootwait:/sbin/rc boot

다시 말씀드리지만 rc 스크립트는 필요한 작업을 수행합니다. 참고로 rc (boot) 에 주어진 옵션은 이것이 사용하는 /etc/runlevels의 하위 디렉터리와 같습니다.

이제 init 는 어떤 실행 레벨을 실행할 지 설정 파일을 확인합니다. /etc/inittab에서 다음 줄을 읽어 들들이고 실행할 실행 레벨을 결정합니다.

파일 /etc/inittab기본 실행 레벨 선택

id:3:initdefault:

이 경우 (대부분의 젠투 사용자들이 사용할 경우), 실행레벨 id는 3입니다. 이 정보를 사용하여 init 은 실행레벨 3을 시작하기 위해 무엇을 실행해야 하는지 확인합니다:

파일 /etc/inittab실행 레벨 정의

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

다시 말해 런레벨 3를 설정하는 줄에서 서비스를 시작하기 위해 (이 시점의 매개변수는 default입니다) rc 스크립트를 사용합니다. 강조해서 말하지만 rc 매개변수는 /etc/runlevels의 하위 디렉터리 이름과 같습니다.

rc 실행이 끝나면 init은 어떤 가상 콘솔을 활성화 할지, 각 콘솔에서 실행할 명령을 결정합니다.

파일 /etc/inittab터미널 정의

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

존재하는 실행 레벨

이전 절에서, init에서 어떤 실행 레벨을 활성화 할지 결정하는 숫자 방식을 활용함을 보았습니다. 실행 레벨은 시스템이 실행중인 상태를 나타내며, 실행 레벨에 진입하거나 벗어날때 실행해야 할 여러가지 스크립트(실행 레벨 스크립트 또는 초기화 스크립트)를 가지고 있습니다.

젠투에서는 세가지의 내부 런레벨과 네가지의 사용자 정의 런레벨 즉, 일곱가지 런레벨을 정의했습니다. 내부 런레벨은 sysinit, shutdown, reboot가 있고 이들 이름이 함축하는 일을 정확하게 수행합니다. 시스템을 초기화하고 시스템을 종료하며 시스템을 다시 시작합니다.

사용자 런레벨은 /etc/runlevels의 하위 디렉터리 boot, default, nonetwork, single과 연결됩니다. boot 런레벨은 모든 기타 런레벨에서 사용하려는, 전체 시스템에서 필요한 서비스를 시작합니다. 나머지 세가지 런레벨은 어떤 서비스를 시작하느냐에 따라 차이가 있습니다. default는 항상 실행할 때 사용하고, nonetwork는 네트워크 연결이 필요하지 않을 때 사용하며, single은 시스템을 복구해야 할때 사용합니다.

초기화 스크립트(initscript) 다루기

rc 프로세스를 시작하는 스크립트를 초기화 스크립트라고 부릅니다. /etc/init.d에 있는 각각의 스크립트는 다음 매개 변수, start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme, broken과 함께 실행할 수 있습니다.

서비스(와 관련 서비스들)를 시작, 중지, 다시 시작하려면 start, stop, restart를 사용해야 합니다:

root #/etc/init.d/postfix start

참고
주어진 서비스에서 필요한 요건은 중지된 상태나 재시작한 상태입니다. 다른 관련 서비스 (서비스를 사용하지만 필요하지 않은) 는 건드리지 않은 상태로 남아있습니다.

서비스를 중단하고 싶지만 다른 관련 서비스는 그대로 둔다면 --nodeps 매개 변수를 stop 명령과 함께 사용할 수 있습니다.

root #/etc/init.d/postfix --nodeps stop

서비스의 상태(시작함, 중단함, 멈춤, 등)가 어떤지 보려면 status 인자를 사용하십시오:

root #/etc/init.d/postfix status

상태 정보에서 서비스가 동작중이라고 알리고 있지만, 실제로 동작중이 아님을 알고 있을 경우 zap 인자를 사용하여 상태 정보를 "중지됨"으로 되돌릴 수 있습니다:

root #/etc/init.d/postfix zap

또한 관련 서비스가 무엇인지 알아보려면 iuse나 ineed를 사용할 수 있습니다. ineed를 사용하면 서비스가 올바른 기능을 다하는데 실제로 필요한 서비스를 볼 수 있습니다. 반면에 iuse를 사용하면 서비스에서 사용할 수 있지만 올바른 동작을 하는데 필요하지는 않은 서비스를 보여줍니다.

root #/etc/init.d/postfix ineed

이와 비슷하게 어떤 서비스를 필요로 하는지(needsme) 어떤 서비스를 사용할 수 있는지(usesme) 확인할 수 있습니다:

root #/etc/init.d/postfix needsme

실행 레벨 업데이트

rc-update

젠투의 init 시스템은 의존 트리를 사용하여 어떤 서비스를 먼저 시작해야 할지 결정 합니다. 사용자 여러분들이 이 지루한 작업을 하지 않도록 실행 레벨과 초기화 스크립트 관리를 쉽게 하는 도구를 만들었습니다.

rc-update를 사용하면 초기화 스크립트를 실행 레벨에 추가하고 제거할 수 있습니다. rc-update 도구는 그 다음 의존 트리를 다시 만들기 위해 depscan.sh를 자동으로 요청합니다.

서비스 추가/삭제

이전 설치과정에서 "default" 실행 레벨에 초기화 스크립트를 추가했습니다. 그 때 여러분은 "default"가 왜 있는지 눈치채지 못하셨겠지만 이제는 알아차리셨을겁니다. rc-update 스크립트는 add, del, show 동작 중 하나를 두번째 매개 변수로 필요로 합니다.

초기화 스크립트를 추가하거나 제거하려면 rc-update 스크립트에 add나 del 매개 변수를 추가하고, 초기화 스크립트 이름과 실행 레벨을 제시하시면 됩니다. 예를 들자면 다음과 같습니다.

root #rc-update del postfix default

rc-update -v show 명령은 사용할 수 있는 실행할 초기화 스크립트와 실행 레벨의 목록을 보여줍니다.

root #rc-update -v show

(-v를 뺀) rc-update show를 실행하여 활성화 한 초기화 스크립트와 실행 레벨만을 보실 수 있습니다.

서비스 설정

왜 추가 설정이 필요한가

초기화 스크립트는 조금 복잡할 수 있습니다. 때문에 오류에 취약하게 만들 수가 있어 사용자가 초기화 스크립트를 올바르게 수정하는게 만족스럽진 않습니다. 그러나 서비스를 설정할 수 있는 방법에 있어서는 중요합니다. 예를 들어 여러분이 서비스 자체에 더 많은 옵션을 주고 싶어할 수도 있습니다.

두번째 이유로는 초기화 스크립트의 외부 설정을 보유하려면, 바꾼 설정을 되돌릴 수 없다는 두려움을 없애고 초기화 스크립트를 업데이트할 수 있어야 하기 때문입니다.

conf.d 디렉터리

젠투에서는 서비스를 설정하는 쉬운 방법을 제공합니다: 모든 초기화 스크립트는 /etc/conf.d의 파일로 설정할 수 있습니다. 예를 들어 apache2 초기화 스크립트(/etc/init.d/apache2)는 Apache 2 서버를 시작할 때 주고 싶은 옵션을 넣을 수 있는 /etc/conf.d/apache2 설정 파일을 지니고 있습니다.

파일 /etc/conf.d/apache2apache2 초기화 스크립트 예제 옵션

APACHE2_OPTS="-D PHP5"

이런 설정 파일에는 서비스 설정을 쉽게 하는 (/etc/portage.make.conf 같은)변수만 들어있습니다. 변수에 대한 더 자세한 정보도(주석을 통해) 제공해줄 수 있습니다.

initscript 작성

Another useful resource is OpenRC's service script guide.

필요한가요

아닙니다. 초기화 스크립트 작성은 보통 젠투가 모든 제공하는 서비스에 대해 준비된 초기화 스크립트를 제공하는 만큼 필요하지 않습니다. 그러나 포티지를 사용하지 않는 서비스를 설치할 때가 있는데, 초기화 스크립트의 거의 대부분을 만들 필요가 있습니다.

젠투용으로 확실하게 작성한 것이 아니라면 서비스에서 제공하는 init 스크립트를 사용하지 마십시오. 젠투의 초기화 스크립트는 다른 배포판에서 사용하는 초기화 스크립트와 호환되지 않습니다! 다른 배포판이 OpenRC를 사용하지 않는 한!

배치

초기화 스크립트의 기본 배치는 아래와 같습니다.

코드 initscript 구성 예제

#!/sbin/openrc-run
  
depend() {
  (Dependency information)
}
  
start() {
  (Commands necessary to start the service)
}
  
stop() {
  (Commands necessary to stop the service)
}

코드 Example initscript layout (updated)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Dependency information)
}
 
start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

어떤 초기화 스크립트든지 start() 함수의 정의가 필요합니다. 다른 모든 부분은 부가적인 요소입니다.

의존성

초기화 스크립트의 준비와 순차진행에 영향을 주는 요소가 무엇인지 지정할 수 있는 의존성 유사 방식에는 use와 need가 있습니다. 순서에 관계된 메서드에는 before과 after가 있습니다. 후자의 두가지 키워드는 그 자체로 의존성을 지니지 않습니다 어떤 스크립트가 시작하도록 계획하지 않았을 때(또는 시작에 실패했을 때) 원 초기화 스크립트의 동작이 실패하지 않도록 합니다.

use 설정은 선택한 스크립트의 기능을 이 스크립트가 사용하지만 직접적인 의존성을 지니지 않도록 init 시스템에 알려줍니다. 좋은 본보기로 use logger나 use dns를 들 수 있습니다. 이 서비스가 존재한다면 사용하기 좋은 상태로 두겠지만 로거나 DNS 서버가 없다 하더라도 서비스는 여전히 동작할 것입니다. 서비스가 존재한다면 use에 있는 스크립트보다 먼저 서비스를 시작합니다.
need 설정은 강한 의존성입니다. 이는 need(필요)한 스크립트일 경우 명시한 스크립트를 성공적으로 실행하기 전에 시작하지 않음을 의미합니다. 또한 언급한 다른 스크립트를 다시 시작하면 마찬가지로 해당 스크립트도 다시 시작합니다.
before를 사용하면, 선택한 요소가 init 레벨의 일부일 경우 선택한 요소를 실행하기 전에 주어진 스크립트를 실행합니다. 그래서 before alsasound를 정의한 xdm 초기화 스크립트는 alsasound 스크립트를 실행하기 전에 시작하겠지만, alsasound가 동일한 init 레벨에서 실행하도록 계획했을 경우에만 해당합니다. alsasound를 시작하도록 계획하지 않았다면, 일부 설정은 효력이 없으며, 스크립트 자신이 가장 적당하다고 여기는 시점에 xdm을 실행합니다.
이와 마찬가지로 after를 사용하면, 선택한 요소가 init 레벨의 일부일 경우 선택한 요소를 실행한 다음에 주어진 스크립트를 실행합니다. 아니면 설정이 효력이 없으며, 적당하다고 여기는 시점에 init 시스템이 스크립트를 실행합니다.

need가 스크립트를 시작하든 아니든 영향을 주는 진성 의존성 설정이라는 점을 분명히 이해해야합니다. 다른 모든 요소는 명령 스크립트를 실행(할 수 있거나 해야)할 수 있을때 init 시스템에 대해 분명히 가리킬 뿐입니다.

이제 젠투에서 사용하는 초기화 스크립트를 살펴보고, 초기화 스크립트가 아닌 의존성 요소를 살펴보십시오. 이"것"을 가상요소라고 부릅니다.

"가상 의존성"은 서비스에서 제공하는 의존성이지만 서비스에서 단독으로 제공하지 않는 의존성입니다. 초기화 스크립트는 시스템 로거에 의존할 수 있습니다만 시스템 로거는 여러가지가 있습니다(metalogd, syslog-ng, sysklogd, ...). 스크립트에서 이들 각자의 단일 모듈(모든 시스템 로거를 설치하고 실행중인지 시스템에서 신경쓰지 않음)을 필요로하지 않기 때문에, 이런 모든 서비스에서 가상 의존성을 제공함을 확인합니다.

Postfix 서비스의 의존성 정보를 살펴보겠습니다:

파일 /etc/init.d/postfixpostfix 서비스 의존성 정보

depend() {
  need net
  use logger dns
  provide mta
}

보시는 바와 같이 Postfix서비스에는 다음과 같은 내용이 있습니다:

(가상)net 의존 요소가 필요합니다 (/etc/init.d/net.eth0 같은 요소로 제공)
(가상)logger 의존 요소를 사용합니다 (/etc/init.d/syslog-ng 같은 요소로 제공)
(가상)dns 의존 요소를 사용합니다 (/etc/init.d/named 같은 요소로 제공)
(가상)mta 의존 요소를 제공합니다 (모든 메일 서버의 공통요소)

순서 처리

이전 장에서 설명한 바와 같이 스크립트를 시작(하고 중지)하는 순서를 어떻게 할지 init 시스템에 알려줄 수 있습니다. 이 순서는 use와 need 의존 설정을 통해 다룰 뿐만 아니라 before와 after로도 순서 설정을 다루기도 합니다. 역시 앞의 설명과 마찬가지로 초기화 스크립트 중 하나의 예제로서 portmap 서비스를 살펴보겠습니다.

파일 /etc/init.d/portmapportmap 서비스 의존성 정보

depend() {
  need net
  before inetd
  before xinetd
}

비록 별로 도움이 되는 이야기는 아니지만, 동일한 실행 레벨의 모든 서비스를 포함하려면 "*" 글롭을 사용할 수 있습니다.

코드 * 글롭 사용

depend() {
  before *
}

서비스가 반드시 로컬 디스크에 기록을 해야 한다면 localmount가 필요합니다. pidfile 같은 것을 /var/run에 두었다면 bootmisc 다음에 실행해야합니다:

코드 localmount가 필요하며 bootmisc 다음에 실행 하도록 의존성 설정

depend() {
  need localmount
  after bootmisc
}

표준 함수

depend() 함수 다음, start() 함수 정의가 필요합니다. 이 함수에는 서비스를 시작하는데 필요한 모든 명령어를 담고 있습니다. 사용자에게 무슨 일이 일어나고 있는지를 알리려면 ebegin과 eend함수를 사용하는 것이 좋습니다.

코드 start() 함수 예제

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Do something in case a restart requires more than stop, start
  fi
  
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

--exec 와 --pidfile는 start와 stop 함수에서 사용합니다. 서비스에서 pidfile을 만들지 못할 경우, 제대로 동작하는지 테스트 하는 겸에 되도록이면 --make-pidfile를 사용합니다. 그렇지 않으면 pidfile를 사용하지 않습니다. 또한 start-stop-daemon의 옵션으로 --quiet를 추가할 수 있지만 서비스에서 너무 많은 메시지를 뿌려대지 않은 이상 추천하는 방법은 아닙니다. --quiet를 사용하면 서비스 시작에 실패했을 때 디버깅 내용을 못볼 수도 있습니다.


위의 예제에서 눈에 띄는 설정은 RC_CMD 변수 내용의 확인입니다. 이전 초기화 스크립트 시스템과는 다르게 새로운 openrc 시스템에서는 스크립트별 다시 시작 기능을 사용하지 못합니다. 대신 함수(start()나 stop())를 다시 시작 과정의 일부로 호출했든지 아니든지간에 RC_CMD 변수의 내용을 스크립트에서 확인해야합니다.

 참고
--exec가 실제로 서비스를 실행하는 쉘 스크립트를 실행하고 나가는 것이 아니라 서비스를 호출하는지 확인하십시오. -- 어떤 초기화 스크립트를 실행할지 고려합니다.

start()함수에 대한 더 많은 예제를 보시려면 /etc/init.d 디렉터리에 있는 초기화 스크립트의 소스 코드를 살펴보십시오.
정의할 수 있(지만 반드시 정의할 필요는 없)는 또 다른 함수로는 stop()이 있습니다. init 시스템은 여러분이 start-stop-daemon을 사용한다면 자체적으로 내용을 채울 정도로 충분히 똑똑합니다.

코드 stop() 함수 예제
 stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

서비스에서 (bash, python, perl과 같은) 다른 스크립트를 실행하고 나중에 이 스크립트의 이름을 (foo.py를 foo로) 바꾼다면 start-stop-daemon에 --name을 추가해야합니다. 여러분의 스크립트를 지정할 때 바꿀 이름으로 반드시 지정해야 합니다. 이 경우 서비스에서는 foo로 이름을 바꾸는 foo.py를 시작합니다.

코드 foo 스크립트 시작 서비스 정의 예제
 start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

참고할 내용이 더 많이 필요할 경우를 대비하여 start-stop-daemon은 최고의 맨 페이지를 보유하고 있습니다:

user $man start-stop-daemon

젠투의 초기화 스크립트 문법은 POSIX 쉘을 기반으로 하기 때문에 자유롭게 초기화 스크립트에 sh-호환 문법 스크립트를 사용할 수 있습니다. init 시스템에서 젠투가 처리할 변경 사항과는 상관 없이 스크립트의 기능이 남아있는지 확인하는, init 스크립트 외적인 배시 맞춤형 구성체처럼 다른 요소도 유지합니다.


개별 옵션 추가


앞서 우리가 언급했던 옵션보다 더 많은 옵션을 초기화 스크립트에서 지원하도록 하려면 extra_commands 변수에 옵션을 추가하고, 옵션 이름과 동일한 함수를 만들어야 합니다. 실례로 restartdelay라고 하는 옵션을 지원하게 해보겠습니다:


extra_commands - Command is available with the service in any state
extra_started_commands - Command is available when the service is started
extra_stopped_commands - Command is available when the service is stopped


코드 restartdelay 메서드 정의 예제
 extra_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

 중요
restart() 함수는 openrc에서 중복 우선적용할 수 없습니다!


서비스 설정 변수

/etc/conf.d의 설정 파일을 지원하려 어떤 내용도 구현할 필요가 없습니다. 초기화 스크립트를 실행하면 다음 파일을 자동으로 참조합니다(예: 사용할 수 있는 변수):

/etc/conf.d/YOUR_INIT_SCRIPT
/etc/conf.d/basic
/etc/rc.conf

또한 초기화 스크립트에 (net과 같은)가상 의존성을 제공하면, (/etc/conf.d/net과 같은) 의존성의 관련 파일도 참조합니다.


실행 레벨 동작 바꾸기


누가 이득을 볼까요


많은 랩톱 사용자들은 이런 상황을 알고 있습니다. 밖에서 (사용할 수 있는 네트워크가 없을 때) net.eth0를 시작하고 싶지 않은데 집에서는 net.eth0를 시작해야 할 때가 있습니다. 젠투에서는 여러분이 실행할 실행 레벨 동작을 바꿀 수 있습니다.


다른 초기화 스크립트를 할당하여 부팅할 수 있는 두번째 "default" 실행 레벨을 만들 수 있습니다. 사용자는 부팅 시간에 활용할 기본 실행 레벨이 어떤 레벨인지 선택할 수 있습니다.


소프트 레벨 사용

제일 먼저, 두번째 "default" 실행 레벨에 대한 실행 레벨 디렉터리를 만드십시오. 다음 예제에서 "offline" 실행 레벨을 만들겠습니다.

root #mkdir /etc/runlevels/offline

새로이 만든 실행 레벨에 필요한 초기화 스크립트를 추가하십시오. 현재 기본 실행 레벨에 net.eth0를 제외한 정확한 복사본을 보유하려면:

root #cd /etc/runlevels/default
root #for service in *; do rc-update add $service offline; done
root #rc-update del net.eth0 offline
root #rc-update show offline
(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

net.eth0을 offline 런레벨에서 제거했지만서도, udev가 감지한 장치를 시작하고 핫 플러그라는 기능의 적당한 서비스를 실행하려 들지도 모릅니다. 기본적으로 젠투는 핫 플러그를 활성화하지않습니다:
핫 플러그 기능을 활성화하지만 선택한 스크립트 모음에 한정하려면, /etc/rc.conf의 rc_hotplug 변수를 사용하십시오:

파일 /etc/rc.confWLAN 인터페이스 핫 플러그 활성화

rc_hotplug="net.wlan !net.*"

 참고
장치 초기화 서비스에 대한 더 많은 내용은 /etc/rc.conf의 주석을 살펴보십시오.

부트로더 설정을 편집하여 오프라인 실행 레벨에 대한 새 항목을 추가하십시오. 해당 항목에서 부팅 매개변수로 softlevel=offline를 추가하십시오.


부트 레벨 사용

bootlevel을 사용하는 것은 softlevel과 완전히 유사합니다. 두번째 "default" 런레벨 대신에 두번째 "boot" 런레벨을 정의하는 점만 다릅니다.

← 포티지 기능 처음 환경 변수 →


환경 변수


도입부


환경 변수는 하나 이상의 프로그램에서 사용하는 정보가 들어있는 이름을 붙인 객체입니다. 수많은 사람은(그리고 리눅스를 처음 접하는) 약간 이상하거나 관리하기가 힘들다는 점을 발견할 것입니다. 그러나, 이렇게 생각하는 것 자체가 실수입니다. 하나 이상의 프로그램의 환경 설정을 바꿀 때 환경 변수를 사용하면 쉽게 처리할 수 있습니다.


중요 예제

다음 표에서는 리눅스 시스템에서 사용하는 많은 변수들을 나열하였고 용도를 설명합니다. 예제 값은 표 다음에 보여드립니다.





변수

설명


PATH

이 변수는 여러분의 시스템이 실행파일을 찾기 위한 콜론으로 구분한 디렉터리 목록을 가집니다. (ls, rc-update, emerge와 같은) 실행 파일의 이름을 입력하였음에도 불구하고 나열한 디렉터리에 이 실행 파일이 없다면 시스템은 (/bin/ls 와 같이 완전한 경로를 지닌 명령을 입력하지 않는 이상) 이 실행 파일을 실행하지 않습니다.


ROOTPATH

이 변수는 PATH와 동일한 기능을 하지만, 루트 사용자가 명령을 입력할때 확인할 디렉터리의 목록만을 가집니다.


LDPATH

이 변수는 동적 링커가 라이브러리를 찾을 콜론으로 구분한 디렉터리 목록을 가집니다.


MANPATH

이 변수는 man 명령어가 man 페이지를 검색할 콜론으로 구분한 디렉터리 목록을 가집니다.


INFODIR

이 변수는 info 명령어가 info 페이지를 검색할 콜론으로 구분한 디렉터리 목록을 가집니다.


PAGER

이 변수는 파일의 내용을 조회할 (less나 more와 같은) 프로그램의 경로를 포함합니다.


EDITOR

이 변수는 파일의 내용을 바꿀 (nano나 vi와 같은) 프로그램의 경로를 포함합니다.


KDEDIRS

이 변수는 KDE 관련 내용을 포함하는 콜론으로 구분한 디렉터리 목록을 가집니다.


CONFIG_PROTECT

이 변수는 포티지를 업데이트 하는 동안 보호해야 할 공백 문자로 구분한 디렉터리 목록을 가집니다.


CONFIG_PROTECT_MASK

이 변수는 포티지를 업데이트 하는 동안 보호하지 않을 공백 문자로 구분한 디렉터리 목록을 가집니다.

아래에서는 이들 변수에 대한 정의의 예를 보실 수 있습니다:


코드 언급한 변수의 설정 예제
 PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"


전역 변수 정의


env.d 디렉터리


젠투에선 변수의 정의를 한곳에 모으려 /etc/env.d 디렉터리를 도입했습니다. 이 디렉터리 안에서 여러분은 00basic, 05gcc 등과 같은 수많은 파일을 찾으실 수 있습니다. 각각의 파일에 들어있는 프로그램에서 필요로 하는 변수들은 프로그램 이름 안에 언급되어 있습니다.


예를 들어 gcc를 설치할 때, 다음 변수의 정의를 가진 05gcc라고 하는 파일을 ebuild가 만들어줍니다.


파일 /etc/env.d/05gcc기본 gcc 활성 환경 변수
 PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"


다른 배포판에서는 바뀐 내용을 알려주거나 각각의 환경 변수 정의를 추가할 때 /etc/profile 등의 위치에 넣습니다. 그러나 젠투에서는 환경 변수를 포함할 수 있는 수많은 파일에 일일히 신경쓰지 않게 여러분과 포티지를 위해 환경변수를 좀 더 쉽게 관리할 수 있게 해줍니다.


예를 들어 gcc를 업데이트하면 사용자 확인 절차 요구 없이 /etc/env.d/05gcc 파일을 업데이트합니다.


이는 포티지 뿐만 아니라 사용자 입장에서의 여러분께도 이득입니다. 때로는 시스템 전체와 관련된 일부 환경 변수를 설정하라고 요청을 받을 수도 있습니다. 아래 예를 통해 http_proxy 변수를 보도록 하겠습니다. /etc/profile을 점점 크게 하는 대신에 (/etc/env.d/99local)파일을 만들고 이 정의 내용을 이 파일에 입력하시기만 하면 됩니다:


파일 /etc/env.d/99local전역 변수 설정
 http_proxy="proxy.server.com:8080"


자체 관리 변수에 동일한 파일을 사용하면, 사용자가 스스로 정의한 변수를 빨리 찾아볼 수 있습니다.


env-update


/etc/env.d/에 있는 수많은 파일에는 PATH 변수를 정의합니다. 이것은 실수가 아닙니다. env-update를 실행하면 환경 변수를 업데이트하기 전에 각 꾸러미에 대한 수많은 정의 내용을 덧붙여서 기존의 값과 혼동하지 않고 제각각이 지닌 환경 변수 값을 쉽게 붙일 수 있도록 합니다.

env-update 스크립트는 /etc/env.d 파일들에 있는 값을 철자 순으로 붙입니다. 파일 이름은 반드시 두자리 숫자로 시작해야 합니다.


코드 env-update의 업데이트 순서
 00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

변수의 결합이 항상 일어나는 일은 아니며 ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, PYTHONPATH 변수들에게만 해당합니다. (/etc/env.d의 철자순 파일에 있는) 다른 변수들에게도 최근 정의한 값을 사용합니다.
COLON_SEPARATED 또는 SPACE_SEPARATED 값 (또한 /etc/env.d/ 파일에 있는 내용도)으로 변수 값을 추가하여 변수 결합 목록에 더 많은 값을 추가할 수 있습니다.
env-update를 실행하면, 스크립트는 /etc/profile.env에 모든 환경 변수를 만들고 이곳에 값을 놓습니다 (이 값은 /etc/profile이 사용합니다). 또한 LDPATH 변수에서 정보를 꺼내와서 /etc/ld.so.conf를 만드는데 사용합니다. 그 다음 ldconfig를 실행하여 동적 링커에서 사용할 /etc/ld.so.cache 파일을 다시 만듭니다.
env-update의 실행 결과를 바로 알고 싶다면 다음 명령을 실행하고 환경을 업데이트 합니다. 자신들만의 젠투 환경을 가진 사용자들은 설치 과정에 있는 다음 명령을 기억할 것입니다.

root #env-update && source /etc/profile

 참고
위 명령은 현재 터미널의 새로운 콘솔과 하위 요소에서 사용할 변수만을 업데이트 합니다. 따라서 X11에서 작업중이라면 여러분이 열어놓은 모든 터미널에서 source /etc/profile명령을 실행하거나 X 를 다시 시작해서 새로운 터미널이 새 변수를 사용할 수 있게해야합니다. 로그인 관리자를 사용하고 있다면 루트 사용자로 로그인해서 /etc/init.d/xdm 를 다시 시작하십시오.

 중요
다른 변수를 정의할 때 쉘 변수를 사용할 수 없습니다. 이는 FOO="$BAR"($BAR는 또 다른 변수)와 같은 구문의 사용을 금지한다는 의미입니다.


지역 변수 설정


사용자별 변수


여러분은 항상 환경 변수를 전체적으로 설정하길 바랄 것은 아닙니다. 이를테면 /home/my_user/bin 을 추가하고 (여러분이 있는) 현재 작업 디렉터리를 PATH변수에 추가하고 싶지만 시스템에 있는 모든 사용자들에게 같은 PATH값을 주고 싶지 않을 때가 있을 것입니다. 이 환경 변수를 지역적으로 설정하고 싶다면 ~/.bashrc나 ~/.bash_profile을 사용해야 합니다.

파일 ~/.bashrc로컬용 PATH 확장

# A colon followed by no directory is treated as the current working directory
PATH="${PATH}:/home/my_user/bin:"

로그아웃/로그인한 수 PATH변수는 업데이트됩니다.


세션별 변수


때로는 더 엄격한 정의가 필요합니다. 바이너리 자신의 경로를 사용하지 않고 임시로 만든 디렉터리에서 바이너리를 사용할 수 있게 하거나 필요에 따라 잠깐 ~/.bashrc를 편집할 수도 있습니다.

이 경우 현재 세션의 PATH 변수는 export 명령으로 설정하십시오. 사용자가 로그아웃하기 전까지는 PATH 변수는 임시 설정으로 사용합니다.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"

← 초기화 스크립트 시스템 처음 파일 및 디렉터리 →





Warning: Display title "젠투 리눅스 ppc 핸드북: 젠투 다루기" overrides earlier display title "Handbook:PPC/Full/Working/ko".

변수	설명
`PATH`	이 변수는 여러분의 시스템이 실행파일을 찾기 위한 콜론으로 구분한 디렉터리 목록을 가집니다. (ls, rc-update, emerge와 같은) 실행 파일의 이름을 입력하였음에도 불구하고 나열한 디렉터리에 이 실행 파일이 없다면 시스템은 (/bin/ls 와 같이 완전한 경로를 지닌 명령을 입력하지 않는 이상) 이 실행 파일을 실행하지 않습니다.
`ROOTPATH`	이 변수는 PATH와 동일한 기능을 하지만, 루트 사용자가 명령을 입력할때 확인할 디렉터리의 목록만을 가집니다.
`LDPATH`	이 변수는 동적 링커가 라이브러리를 찾을 콜론으로 구분한 디렉터리 목록을 가집니다.
`MANPATH`	이 변수는 man 명령어가 man 페이지를 검색할 콜론으로 구분한 디렉터리 목록을 가집니다.
`INFODIR`	이 변수는 info 명령어가 info 페이지를 검색할 콜론으로 구분한 디렉터리 목록을 가집니다.
`PAGER`	이 변수는 파일의 내용을 조회할 (less나 more와 같은) 프로그램의 경로를 포함합니다.
`EDITOR`	이 변수는 파일의 내용을 바꿀 (nano나 vi와 같은) 프로그램의 경로를 포함합니다.
`KDEDIRS`	이 변수는 KDE 관련 내용을 포함하는 콜론으로 구분한 디렉터리 목록을 가집니다.
`CONFIG_PROTECT`	이 변수는 포티지를 업데이트 하는 동안 보호해야 할 공백 문자로 구분한 디렉터리 목록을 가집니다.
`CONFIG_PROTECT_MASK`	이 변수는 포티지를 업데이트 하는 동안 보호하지 않을 공백 문자로 구분한 디렉터리 목록을 가집니다.