포테이지는 매우 강력하고 진보적인 패키지 관리 시스템이다. 단순한 빌드 엔진으로든 리눅스 배포판의 핵심으로든 쓰일 수 있는 유연성과 성능 덕택에 젠투는 메타-배포판 엔진이라고 불리기도 한다. 젠투 리눅스 배포판은 포테이지로 구축된다.
젠투 리눅스 자체는 종종 메타-배포판이라고 불린다. 젠투는 포테이지와 ebuild라는 패키지 구축 방법에 대한 1,500여개의 파일로 이루어져 있다. 이 ebuild들은 포테이지 엔진에게 소프트웨어 패키지를 어떻게 컴파일하고 설치할 지를 알려준다. 시스템의 성능을 향상시키기 위해 사용자나 개발자들은 포테이지로 패키지를 설치하고 관리할 수 있으며 포테이지는 profile과 command-line 유틸리티인 emerge로 사용할 수 있다.
젠투 리눅스 시스템은 "즉시 컴파일" 된다. 젠투 리눅스의 설치는 컴파일러의 적절한 셋업과 환경 구축까지 포함하는 작업이며 이는 포테이지가 인터넷에서 "핵심(core)" 부분을 제외한 시스템의 나머지 부분과 필요한 어플리케이션의 소스를 다운받아 구축할 수 있다(역주 - 핵심부분은 물론 설치 전에 여러분이 다운받아 놨을 것이다). 물론, 포테이지도 이미 컴파일된 바이너리 패키지를 지원하긴 하지만 그것은 일종의 절충안이며 (컴파일 하기에) 느린 컴퓨터나 설치된 패키지의 빠른 복구가 필요한 개발자들 및 아주 오래된 머신에서 쓰기 위해 더욱 빠른 컴퓨터에서 컴파일된 패키지를 원하는 유저를 위한 것이다.
여기에다가 포테이지는 패키지의 컴파일이나 설치를 다루는 과정들을 자세하게 설정할 수 있다는 점 때문에 서로 동일하게 설치된 젠투 리눅스 환경은 찾기 힘들다. 실제로, 사용자가 젠투 리눅스를 설치할 때 포테이지 시스템은 사용자가 정의한 포테이지의 설정과 ebuild에 명시된 옵션들에 따라 최적화된 리눅스 배포판으로 컴파일한다.
처음 볼 때 포테이지에 담긴 개념은 전통적인 BSD 포트 시스템(역주 - port를 이용한 패키지 관리 방식은 BSD유닉스에서 처음 사용했고 지금도 Free BSD등에서 사용되고 있다)과 비슷하게 보일 것이다. 양쪽 다 소스로부터 패키지들을 컴파일하며 사용자들이 안전하게 소프트웨어를 설치하거나 제거할 수 있게 해주고 의존성 역시 자동적으로 관리된다. 포테이지의 많은 아이디어가 BSD 포트 시스템에서 빌려 온 것이긴 하지만 포테이지는 "포트의 유사품(ports ripoff)"은 확실히 아니다.
포테이지 시스템은 Python으로 만들어진 핵심 부분과 Ebuilds에 기초한 Bash 스크립트로 만들어졌다. Makefile과 make 명령어를 쓰는 대신, 포테이지는 현재의 포트 시스템증 최고라는 생각이 들만큼 독보적이고 우수한 시스템을 만들기 위해 Python의 강력함과 어느 정도의 객체지향성을 지닌 편리한 쉘 스크립트를 조화롭게 사용했다.
포테이지의 더욱 진일보한 특징 몇가지를 얘기하자면 포테이지 트리의 동일한 패키지의 서로 다른 버전과 수정본들을 관리하는 기능, 조건별 의존성 결정과 요소 지원, 잘 정리된 패키지 관리, sandbox를 이용한 안전한 설치, 설정 파일 보호, profiles 등등이 있다. 이러한 특징들은 이 매뉴얼의 뒷부분에서 더욱 자세히 다룰 것이다.
포테이지 시스템은 최고의 유연성을 갖고 있다. 전통적인 BSD 포트 시스템들은 포트 트리의 하나의 패키지에서 하나의 버전만 지원하는 경향이 있다. 하지만 포테이지는 그러한 제한이 없으며 동일한 패키지의 서로 다른 버전을 설치하는 것도 가능하다. '어떤 패키지의 설치를 위해 그 이전에 설치될 필요가 있는 패키지들'을 뜻하는 패키지의 의존성은 버전이 명시된 이름, 혹은 명시되지 않은 이름으로 표시가능하다. 이는 트리에서 서로 다른 버전들을 유지하는 것을 안전하게 만든다.
의존성 시스템은 또한 조건별 의존성을 지원한다. 포테이지에는 USE 세팅 시스템이라 불리는 우수한 개념이 있다. 여러분은 포테이지 설정 파일에서 설정 변수 한 가지만 변경하더라도 컴파일시에 어떤 패키지들에든 적용되는 특정한 요소나 라이브러리들을 위한 부가적인 기능지원을(그리고 그것이 필요한 것들까지) 불가능하게 만들 수 있다. 이는 다음 장에서 더 자세히 설명할 것이며 매우 유연하고 강력한 시스템이다.
또한 포테이지에는 SLOT이란 개념이 있다. 젠투 리눅스의 개발 도중 개발자들은 종종 패키지들의 의존성을 만족시키기 위해 특정한 패키지들(라이브러리 등)은 서로 다른 버전을 설치할 필요가 있음을 알았다. 이러한 문제를 해결하기 위한 전통적인 접근 방식은 약간씩 다른 이름을 붙임으로써 동일한 패키지의 다른 버전들을 다루는 것이었다.
개발자들은 일정한 버전을 구분된 패키지들처럼 다루는 것을 배우는 대신 포테이지가 SLOT의 사용을 통해 동일한 패키지의 서로 다른 버전들을 관리할 수 있도록 만들었다. 예를 들어 freetype이라는 일반적인 라이브러리의 경우를 생각해 보라. 1.x 계열의 freetype은 2.x 계열과 호환되지는 않지만 여러 가지 패키지들의 의존성을 만족시키기 위해서는 두 가지 모두 필요하다. 대부분의 배포판들과 포트 시스템들은 1.x인 "freetype" 패키지와 2.x인 "freetype2"를 가지고 있는 경향이 있다. 우리는 이러한 접근방법이 치명적으로 패키지 관리 시스템을 붕괴시킬 수 있는 신호라고 생각한다. 우리는 단순히 처음 패키지에는 SLOT번호 1을, 두번째 패키지에 2를 부여한다. 포테이지는 이 정보로 두 가지 버전을 모두 파악할 수 있으며 만약 더욱 상위 버전이 어느 쪽이든 업데이트 되면 그에 따라 업그레이드 하게 된다.
포테이지는 profile이란 개념을 지원한다. profile은 포테이지가 사용하는 기본 설정 옵션 및 지시사항과 함께 패키지 이름들과 버전들의 리스트를 갖고 있다. profile은 포테이지에게 허용되거나 차단되어야 할, 혹은 요구되는 패키지들이 어떤 것이고 어떤 버전인지를 알려준다. 사용자들은 단순히 심볼릭 링크(/etc/make.profile)를 바꾸는 것만으로 profile을 바꿀 수 있다. 단순하게 보일 지도 모르지만 이것은 포테이지가 배포판의 핵심부분을 구성할 수 있도록 하며 전문적인 수준의 구축 시스템으로 평가받을 수 있게 해준다.
젠투 리눅스 배포판을 만들기 위한 수많은 노력은 포테이지에 쓰이는 ebuild 파일들과 profile이란 결과로 나타났다. profile에는 시스템의 동작에 필수적인 "핵심"으로서 어떤 패키지들이 고려되어야 하는지 정의되어 있다. profile은 또한 일시적으로 잘못되어 패키지 사용이 불가능한 경우 등에 개발자들이 필요에 따라 특정한 패키지와 버전을 차단하거나 해제할 수 있게 해준다. ebuild 파일들은 포테이지에게 단순히 profile이 요구하거나 허용하는 패키지를 실제로 어떻게 설치하는지 알려줄 뿐이다.
이후의 내용은 사용자들이나 개발자들 모두에게 중요한 포테이지 설정의 여러 가지 부분을 다루고 있다. 포테이지는 아주 유연한 시스템이다. 여러분은 여러분의 시스템을 책임지고 있는 포테이지를 설정하는 방법을 알 필요가 있으며 여러분의 필요에 따라선 시스템을 최적화할 수도 있을 것이다.
이 문서에서 "사용자들" 이라는 표현은 포테이지를 쓸 수 있고 시스템의 설정을 변경할 수 있는 관리자의 권한을 가지고 있는 사람들을 의미한다. 포테이지의 설정을 바꾸거나 패키지들을 merge 혹은 unmerge(역주 - 젠투에서 쓰이는 용어로 일반적인 install, uninstall과 같은 의미라고 보면 무방하다. 그러므로 번역도 이에 따른다) 하기 위해서는 root로 억세스해야 한다.
아래서 거론되는 거의 대부분의 설정 옵션들은 /etc/make.conf와 /etc/make.global에서 찾을 수 있다. 중요한 점은 /etc/make.conf에 정의된 세팅은 거의 대부분 /etc/make.global에 정의된 세팅에 우선한다는 것이다. /etc/make.conf 와 /etc/make.global의 모든 것은 포테이지와 관계된 시스템의 전반적이고 전체적인 설정이라고 볼 수 있다.
이미 정의된 옵션이 어디 있는지 찾아야 한다면 우선 /etc/make.conf를 체크하고, 그 후에 /etc/make.globals를 뒤져 보기를 권한다. 특별히 명시되어 있지않다면, /etc/make.conf에 있는 옵션들은 /etc/make.globals에 있는 옵션들에 우선한다(역주 - 중요하다고 이미 얘기했다, 밑줄쳐라 -_-).
USE 세팅 시스템은 전체적으로든 개별적으로든 패키지를 설치하는 시점에 여러 가지 특성을 가능하거나 불가능하게 할 수 있는 유연한 방식이다. 이는 관리자가 패키지가 컴파일 될 때의 부가적인 요소들에 관해 어떻게 빌드될 것인가를 제어할 수 있게 해준다. 예를 들면, GNOME 지원이 선택적인 패키지들은 gnome USE 세팅을 불가능하게 하여 컴파일시에 이 지원을 못하게 만들 수 있다. 물론 gnome USE 세팅을 가능하게 하는 것은 GNOME 지원을 가능하게 한다.
패키지들의 USE 세팅은 소프트웨어 자체와 패키지의 ebuild 모두 USE 세팅을 선택적으로 지원을 하는지의 여부에 따라 영향력을 발휘할 수 있다. 만약 소프트웨어가 선택 요소를 지원하지 않는다면 그에 따른 USE 세팅은 당연히 아무런 영향도 없을 것이다. 또한 많은 패키지 의존성들은 소프트웨어에 의한 선택적인 부분이 고려되지 않으므로 USE 세팅들은 그러한 강제적인 의존성들에 영향을 미치지 않을 것이다. 특정한 패키지에 의해 사용된 USE 키워드들의 목록은 어떤 ebuild 파일에서든 DEPEND와 RDEPEND 라인들에서 찾아볼 수 있다.
젠투 리눅스에 의해 사용된 USE 세팅들의 목록은 /usr/portage/profiles/use.desc에서 찾아볼 수 있다. 각 USE 세팅은 한 줄에 하나씩 USE 세팅의 역할에 대한 간략한 설명과 함께 씌어져 있다.
포테이지는 서로 다른 네 곳을 확인하여 USE 세팅이 가능한지 불가능한지 결정한다. 이러한 확인 장소들은 "스택" 방식으로 USE 세팅들을 바꾼다. 포테이지는 각 장소를 통과하면서 이전 장소의 세팅이 가능한지 불가능했는지를 기억한다. USE 세팅의 변경은 포테이지가 각 위치를 지나는 동안 누적된다.
USE 세팅의 계산중 체크되는 장소들과 포테이지가 그 곳들을 검토하는 순서는 /etc/make.globals에 있는 USE_ORDER에 의해 설정된다. 한 장소를 쓰지 않으려면 단순히 USE_ORDER에서 제거하기만 하면 된다.
다음은 포테이지의 기본 설정에 있는 USE_ORDER에 의해 정의된 순서에 의한 각 장소에 대한 설명이다.
Defaults
포테이지 프로필들은 기본적인 USE 키워드들을 정의할 수 있다. 이것은 어떤 포테이지 profile이든지 make.defaults 파일에 정의되어 있다. /etc/make.profile이 현재 사용 중인 포테이지 profile의 링크로 사용된다면 /etc/make.profile/make.defaults가 기본값의 집합이 된다. 이것은 여러분이 수정하더라도 나중에 profile이 덮어씌어질(overwrite) 가능성이 있으므로 편집하지 말 것을 권한다.
Auto
이것은 포테이지 profile의 use.defaults에 정의되어 있다(/etc/make.profile/use.defaults). 각 엔트리는 USE 세팅과 그에 따른 패키지로 구성된다. USE 키워드에 나열된 패키지가 현재 설치되어 있다면 USE 세팅은 가능한 것으로 간주된다. 예를 들어, 여러분이 x11-base/xfree를 설치했고 다음에 지나갈 장소에 X USE 세팅을 명백하게 불가능하도록 만든 것이 아니라면 X 키워드는 패키지가 설치되어 있는 동안은 전체적으로 동작할 것이다. 마찬가지로 이것은 여러분이 수정하더라도 나중에 profile이 덮어씌어질 가능성이 있으므로 편집하지 말 것을 권장한다.
Conf
만약 USE 설정 옵션이 /etc/make.conf에 정의되어 있다면, 여기에 정의된 USE 세팅들도 포함된다. 만약 make.conf에 USE 세팅이 없다면 /etc/make.globals가 체크된다. 이 값은 다음과 비슷할 것이다 :
USE="slang readline gpm berkdb gdbm tcpd pam libwww ssl gb tk
lm_sensors lvm ldap tex bonobo sdl gtk xfs evo pda ldap
mmx mitshm perl python guile ruby postgres dvd 3dnow tcl
lcms gif sdl vorbis ogg oss libg++ directfb decss snmp
gnome X opengl mozilla pdflib gpg -nls gd xface jpilot
-kde -qt -esd -motif -alsa oggvorbis"
USE 세팅은 간단히 이름만 써넣으면 가능하다. 또한 USE 세팅은 세팅 이름 앞에 '-'를 붙이면 작동하지 않게 된다. 예를 들어, gnome은 GNOME 키워드를 가능하게 하고 -motif는 motif 키워드를 사용 불가능하게 만듭니다.
/etc/make.conf에 있는 USE 세팅은 확실하게 키워드를 가능 혹은 불가능하게 만들기 위해 권장되는 장소이다. 이 파일은 포테이지에 의해 자동으로 덮어쓰이지 않는다. 이전의 두 곳에서 당신이 원하지 않는 방향으로 설정되어 있던 USE 키워드들을 여기서 가능하게 혹은 불가능하게 표시할 것을 권장한다.
Env
USE 키워드 세팅은 쉘 환경 세팅을 사용하므로 수동적인 방법으로 무효화될 수도 있다.
export USE="-gnome" emerge net-im/gaim
이것은 하나나 그 이상의 패키지들의 설치를 위해 특정한 USE 세팅들을 사용하게 해 준다. 쉘 환경에서 USE를 세팅 후 emerge를 사용하는 것은 emerge가 그 쉘에서 동작하고 USE가 계속 세팅되어 있는 경우에만 효과가 있을 것이다(역주 - export 명령 자체가 그렇긴 하지만 이는 쉘을 빠져 나갈때까지만 유효하단 의미이다).
패키지를 컴파일할 때 포테이지가 사용하는 컴파일러 옵션은 /etc/make.conf에 있는 CHOST, CFLAGS 및 CXXFLAGS 변수들을 고쳐 세팅할 수 있다. CHOST는 어떤 플랫폼에서 컴파일 되는지를 표시하며 CFLAGS와 CXXFLAGS는 각각 C와 C++ 소스를 컴파일할 때 사용되는 컴파일 플래그를 의미한다.
기본적인 세팅의 많은 것들이 어떤 플랫폼에서 사용되는지에 대한 설명과 함께 제공된다. 이 제공되는 기본값들은 안정적이라고 판단되는 것이며 검증된 것이다. 이 세팅들을 변경하는 것은 컴파일러와 컴파일되는 소프트웨어 양쪽에서 에러와 버그를 발생시킬 수도 있다. 기본 세팅을 수정해 최적화 하기로 마음먹었다면 혹시 시스템을 망가뜨릴 수도 있으므로 주의하기 바란다.
멀티 프로세서 시스템들의 사용자들은 /etc/make.globals에서 찾을 수 있는 MAKEOPTS 옵션을 수정해서 더 나은 성능을 얻을 수 있다. 이 옵션은 패키지 컴파일시에 gcc의 다중 수행이 가능하도록 make에 전달된다.
포테이지에서는 패키지들을 빌드할 때 사용하거나 여러 파일들을 저장할 때 사용하는 디렉토리들을 설정할 수 있다. 대부분의 사용자들은 이러한 위치들을 바꿀 필요가 없을 것이다. 다음 옵션들이 세팅 가능하다 :
포테이지는 세팅에 표시된 디렉토리들에 있는 모든 설정 파일들을 보호한다. 포테이지는 보호된 디렉토리에 있는 파일들은 덮어 쓰지 않을 것이다. 만약 패키지가 이미 존재하는 파일을 설치하고자 한다면 ._cfg0000_name과 같은 식으로 이름이 바뀔 것이다. 이것은 사용자들이 후에 새로운 파일을 보고 두 설정 파일의 다른 부분을 직접 고쳐서 합칠 수 있게 하기 위함이다.
보호 디렉토리들은 /etc/make.conf 혹은 /etc/make.globals에 있는 CONFIG_PROTECT로 설정할 수 있다. 또한 특정 파일과 서브 디렉토리는 CONFIG_PROTECT_MASK에 세팅해서 보호되지 않게 할 수 있다.
다음은 예제이며 무턱대고 복사해 쓰지 말기 바란다 :
CONFIG_PROTECT="/etc /usr/share/config /usr/kde/2/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/pam.d"
사용자들은 쉘에서 다음 명령어로 설정 파일 보호가 어떻게 수행되는지에 대해 더 많은 정보를 얻을 수 있다 :
emerge --help config
포테이지는 패키지 설치의 여러 단계에서 포테이지가 동작하고 설치 후 마무리하는 과정까지 관리하는 개발자들에게 적합한 여러가지 옵션들을 제공한다. 이 옵션들은 단지 개발자들의 편의를 위한 것이며 사용자들에게는 문제들을 일으킬 수도 있다.
가능한 특성들의 리스트는 /etc/make.conf 혹은 /etc/make.globals에 있는 FEATURES에서 설정할 수 있다. 다음은 사용 가능한 옵션들의 목록이다 :
포테이지는 rsync나 익명 CVS로 포테이지 트리을 업데이트하는 기능을 가지고 있다. 여러분은 포테이지가 어떤 방법을 사용할지 /etc/make.conf의 SYNC 세팅을 통해 정의할 수 있다.
RSYNC
사용자들이 자기 자신의 ebuild 파일들을 개발할 계획이 아니라면 rsync를 사용하기를 권장하는데, 익명 CVS를 사용하는 것보다 서버에 훨씬 적은 로드를 주기 때문이다. 이때문에 rsync는 /etc/make.conf의 기본 설정으로 되어 있다. 이는 다음과 같이 설정된다 :
SYNC="rsync://cvs.gentoo.org/gentoo-x86-portage"
익명 CVS
포테이지는 로컬 머신의 포테이지 트리를 특정한 익명 CVS와 비교하여 동일하게 유지할 수 있다. 이는 포테이지가 공식 트리와 동기화될 때 자신이 수정한 것이 덮어쓰여 사라져 버리기를 원치 않는 개발자들에게 유용할 것이다. 이 방법은 다음과 같이 설정할 수 있다:
SYNC="cvs://:pserver:anonymous@gentoo.org:/home/anoncvs"
당신의 머신의 트리를 공식 포테이지 트리와 동일하게 만들기 위해 익명 CVS를 사용하기에 앞서, 다음을 실행하여 cvs 툴로 트리의 사본을 "검토"해야 한다 :
# 이전의 포테이지를 백업한다 cd /usr mv portage portage.old # 트리를 "검토"한다 cvs -d :pserver:anonymous@gentoo.org:/home/anoncvs login # 패스워드를 묻는 프롬프트가 나오면 엔터를 친다 cvs -d :pserver:anonymous@gentoo.org:/home/anoncvs co gentoo-x86 # 새로운 트리를 옮긴다 mv gentoo-x86 portage
개발자 CVS
CVS 트리에 완전히 접근할 수 있는 개발자들은 RSH 혹은 SSH를 통해 접근할 수 있는 CVS 저장소와 비교하여 자신의 트리를 emerge로 동기화 할 수 있다.
간단히 여러분의 계정을 사용하여 CVS 트리를 검토하고, /usr/portage로 옮기고, 다음의 SYNC 옵션을 사용하도록 한다 :
SYNC="cvs://youraccount@cvs.gentoo.org:/home/cvsroot"
젠투 프로젝트는 포테이지 트리의 ebuild들에 명시된 모든 압축 파일들의 자체 미러를 갖고 있다. 때때로 새로 나온 버전의 소스 tarball파일등의 경우 다운이 될 수도 있는 느린 서버들에 저장된다. 또한 개발자들은 새로운 릴리즈가 만들어지면 ftp에서 이전 버전은 지워버릴 것이다. 젠투를 쓰는 사람들의 편안한 삶을 위해 :) (그리고 최신 소스가 있는 서버의 부담을 줄이기 위해) 우리는 이러한 파일들을 미러링한다. 이는 여러분의 실제 위치에 가까운 미러 사이트로부터 파일들을 더 빠르고 안정적으로 다운받을 수 있게 해줄 것이다.
여러분이 패키지를 설치하고자 하면 포테이지는 필요한 파일들을 찾기 위해 먼저 젠투의 미러 사이트를 체크할 것이다. 만약 미러 사이트에 파일이 없다면 포테이지는 패키지 ebuild에 기록된 HTTP 서버나 FTP 서버로부터 다운로드를 시도할 것이다.
포테이지가 사용하는 미러는 /etc/make.conf에 있는 GENTOO_MIRRORS에 쓰여있다. 다음은 현재의 기본 설정이다 (역주 - 지금은 아래 미러가 쓰이지 않는다):
GENTOO_MIRRORS="http://www.ibiblio.org/gentoo"
여러분과 가까운 젠투 미러를 찾으려면 젠투 웹 사이트를 검색하거나 가까운 메일링 리스트에 질문하기 바란다.
포테이지가 파일을 다운로드 하는데 사용하는 프로그램은 FETCHCOMMAND와 RESUMECOMMAND를 세팅해서 설정할 수 있다. 몇 가지 예를 /etc/make.conf와 /etc/make.globals에서 볼 수 있을 것이다. 포테이지는 디폴트로 대부분의 사용자들에게 적합한 wget을 사용한다.
포테이지는 파일들을 다운로드할 때 HTTP와 FTP 프록시를 모두 쓸 수 있다. 프록시는 /etc/mank.conf나 /etc/make.globals에 있는 HTTP_PROXY와 FTP_PROXY로 설정할 수 있다. 만약 HTTP와 FTP가 동일한 프록시를 사용한다면, 여러분은 앞의 두 가지 설정 대신 PROXY를 설정하면 된다.
다음은 예제이다 :
HTTP_PROXY="http://192.168.1.1:8080" FTP_PROXY="http://192.168.1.1:8080" or PROXY="http://192.168.1.1:8080"
포테이지는 RSYNC 사용을 위해 HTTP 프록시를 쓸 수도 있고 혹은 RSYNC_PROXY를 /etc/make.conf에 설정하거나 환경 변수로 설정해 쓸 수도 있다.
다음은 예제이다 :
RSYNC_PROXY="192.168.1.1:8080"
다음은 사용자들이 쓸 수 있는 부차적인 옵션들입니다:
/usr/portage 에 위치한 포테이지 트리는 다양한 패키지들의 빌드 명령어들(ebuilds라고 한다)의 라이브러리를 갖고 있다. 이 트리에는 또한 여러분의 시스템을 최신으로 유지하기 위해 필수적인 profile과 package.mask의 정보가 있다. 최근 버전의 패키지들과 버그 패치들을 갖추려면 이 트리를 늘 공식 포테이지 트리와 동일하게 업데이트하는 것이 중요하다. 여러분은 다음의 명령어로 포테이지 트리를 업데이트 할 수 있다.
emerge rsync
emerge가 컴퓨터의 포테이지 트리를 업데이트하기 위해 사용하는 방법은 바뀔 수도 있다. 더 많은 정보는 포테이지 설정하기에 있는 포테이지 SYNC 세팅에 있다.
포테이지로 패키지를 컴파일하거나 설치하는 것을 merging이라고 한다(역주 - 업데이트의 의미도 있지만 이후 그냥 '설치'로 번역함). 포테이지는 패키지들을 컴파일하고 설치된 파일이 기록되는 "image" 디렉토리에 임시로 설치한다. 이 파일들은 이후 image 디렉토리에서 실제 root 파일 시스템으로 옮겨져 합쳐진다.
emerge명령은 포테이지 시스템의 인터페이스로 사용된다(역주 - 다시 말해 emerge를 쓰는 것이 바로 포테이지를 쓰는 것입니다! ^^). 패키지의 설치와 제거는 이 명령어와 여러 가지 명령어 옵션(argument)을 사용해서 통제할 수 있다.
어떤 패키지의 최신 버전을 설치하려면 간단하게 다음처럼 패키지 이름을 써주면 된다 :
emerge galeon
위 명령을 실행시키면 의존관계에 있는 필요한 패키지들을(USE 세팅과도 적절한) 컴파일하고 설치한 후 galeon의 mask되지 않은(역주 - 안정성이 검증되지 않거나 한 경우 버전 사용이 금지된 것을 mask되었다고 함) 최신 버전을 컴파일하고 설치할 것이다. Galeon은 또한 카테고리와 함께 완전한 이름으로 다음처럼 쓸 수도 있다 : net-www/galeon
emerge 명령은 또한 실제 ebuild 파일들의 정보를 이용하기도 한다. 이는 사용자들이 선택한 패키지의 이전 버전이나 third party(역주 - 패키지를 실제 개발한 곳을 의미) ebuild에 기초한 패키지들을 설치할 수 있도록 한다. 다음은 예제이다 :
emerge /usr/portage/net-www/galeon/galeon-1.2.0-r3.ebuild
설치될 패키지 이름이나 ebuild 파일 이름을 명시하는 것말고도 emerge는 몇 가지 아주 유용한 옵션들을 지원합니다. 이런 옵션들 중에서 --pretend는 아마 가장 유용할 것이다. 이 옵션이 사용되면 의도했던 명령은 수행되지 않는다. 대신 포테이지는 명령이 수행될 때 설치 혹은 업데이트가 될 패키지들의 목록을 출력한다.다음 예제는 kdevelop 패키지의 최신 버전을 설치하는 동안 설치되거나 업데이트 될 패키지의 리스트이다 :
root@kodiak blocke # emerge --pretend kdevelop These are the packages that I would merge, in order. Calculating dependencies ...done! [ebuild N ] kde-base/kdelibs-2.2.2-r4 to / [ebuild N ] dev-util/kdbg-1.2.2 to / [ebuild U ] app-text/psutils-1.17 to / [ebuild U ] app-text/a2ps-4.13b-r3 to / [ebuild U ] app-text/jadetex-2.20 to / [ebuild N ] app-text/sgmltools-lite-3.0.3-r2 to / [ebuild N ] kde-base/kdoc-2.2.2-r1 to / [ebuild N ] net-www/htdig-3.1.5-r2 to / [ebuild N ] app-text/enscript-1.6.3-r1 to / [ebuild N ] kde-base/kdebase-2.2.2-r2 to / [ebuild N ] app-doc/qt-docs-2.3.1 to / [ebuild N ] dev-util/kdevelop-2.0.2 to /
위의 목록에서 N으로 표시된 패키지들은 아직 설치되지 않았지만 이 명령으로 설치될 패키지들이다. U로 표시된 패키지들은 이전 버전이 설치되어 있으며 이 명령으로 패키지가 업그레이드가 될 것임을 뜻한다.
사용 가능한 다른 옵션들이다 :
--fetchonly : 실제 설치될 패키지와 의존성을 만족시키는 패키지들을 컴파일하는데 필요한 압축파일들을 다운로드한다 (역주 - 설치는 하지 않는다는 뜻).
--emptytree : 이 옵션은 포테이지가 패키지와 의존성을 만족하는 패키지들이 모두 설치되지 않은 것으로 인식한다. 이는 --pretend와 함께 쓰면 어떤 특정한 패키지의 완전한 의존성 트리를 보여주는데에 유용하다. glibc를 위한 것들은 제외한 모든 것이 출력된다.
--nodeps : 포테이지는 어떤 의존성이든 무시하고 패키지를 설치하려고 시도할 것이다. 만약 여러분이 의존성에 적합한 패키지들을 미리 설치하지 않았다면 컴파일은 실패할 수 있다.
--onlydeps : 패키지의 의존성을 만족시키기 위한 것들만 설치된다. 지정한 패키지는 설치되지 않는다.
--noreplace : 이미 설치되어 있다면 패키지의 설치를 생략한다.
--usepkg : 포테이지가 패키지를 컴파일 하는 대신 지정된 위치의 이미 컴파일된 tbz2 패키지들을 사용하려고 시도할 것이다. 이 위치는 쉘의 환경 변수 PKGDIR에 정의된다.
--debug : ebuild 환경은 매우 세밀하도록 구성된다. 이 옵션은 개발자들이 ebuild에 기초한 bash 스크립트의 문법적 에러들을 추적할 때 유용하다.
--autoclean : emerge가 패키지의 빌드를 시작하기 전에 패키지별로 지정된 임시 빌드 디렉토리들을 강제로 청소하도록 한다. 포테이지는 기본적으로 청소작업을 하게 되어 있으므로 개발자가 이런 디폴트를 불가능하게 해놓았을 경우에만 이 옵션이 유용할 것이다.
--verbose : emerge가 더 많은 정보를 표시하게 한다. 현재 이것은 GNU info 에러들이 보이도록 할 뿐이다. 이 에러들은 사용자들이 무시해도 안전하다.
"unmerging"은 파일 시스템으로부터 설치된 패키지와 관련 파일들을 제거하는 것이다. 패키지의 소프트웨어는 시스템으로부터 제거되며 재설치하지 않는다면 더 이상 사용할 수 없다.
emerge와와 옵션 unmerge 뒤에 패키지 이름을 입력하면 패키지는 제거된다. 다음 예제는 ltrace 패키지의 설치된 모든 버전들을 제거할 것이다 :
emerge unmerge ltrace or emerge unmerge dev-util/ltrace
포테이지는 또한 패키지의 특정한 버전들만 제거할 수도 있다. 범위는 =(같은 버전), <(더 낮은), >(더 높은), <=(이하), >=(이상)으로 표시된다. 다음은 ltrace의 0.3.15버전이나 그 이전 버전들을 모두 제거한다 :
emerge unmerge \<=dev-utils/ltrace-0.3.15
패키지 범위를 표시할 때 >와 <앞에 escape 문자를 사용해서 쉘이 일반적인 문자로 인식하도록 하는 것이 중요하다. 또한 예제에서처럼 패키지 이름에 카테고리를 명시해 줄 필요가 있다. 어떻게 패키지 범위를 표시하는지 또 다른 예를 보려면 emerge --help를 이용하라.
만약 패키지가 실제로 설치되어 있다면 emerge 프로그램은 어떤 패키지들이 제거될 것인지 정확하게 보여주고 사용자가 취소할 시간을 위해 지정된 시간(초) 동안 대기할 것입니다. 이 대시 시간동안 사용자는 Control-C를 눌러서 파일 제거를 시작하기 전에 취소할 수 있다.
일단 제거가 시작되면 여러분은 패키지와 관련된 파일 이름들이 쭉 출력되는 것을 볼 수 있을 것이다. 이 중 어떤 것들은 파일 이름 왼쪽에 플래그를 가지고 있을 것이다. !mtime, !empty, 그리고 cfg는 패키지가 제거되는 동안 해당 파일들이 제거되지 않은 이유를 의미한다. 리스트에서 이런 플래그가 표시되지 않은 파일들은 파일 시스템에서 성공적으로 제거된 것이다.
!mtime 플래그는 패키지의 제거할 버전이 설치된 이후에 수정되었음을 뜻한다. 이는 누군가가 패키지 설치 후에 이 파일을 편집했거나 다른 패키지가 이후에 이 파일을 덮어 썼다는 뜻이다. 이것은 이전에 설치된 버전을 제거하면 필수적인 중요한 파일들도 함께 지워질 거란 걱정 없이 새로운 버전들로 업데이트 하게 해준다.
!empty는 포테이지가 디렉토리가 비어있지 않아서 삭제를 거부한 디렉토리들을 말한다. (여러 패키지들은 종종 동일 디렉토리에 대해 소유권을 갖는다). cfg 플래그를 봤다면 설정 파일 보호가 일어난 것이다. 이는 새로 설치된 패키지가 어떤 설정 파일의 소유권을 가지려 하며 포테이지는 이전 설정파일의 삭제를 거부한다는 뜻이다.
포테이지는 명령어를 하나로 설치된 패키지들을 자동으로 업그레이드하는 기능을 지원한다. 시스템 업데이트라는 특징은 중심 개발자들이 젠투 리눅스의 작동에 중요하다는 이유로 권하는 "핵심" 패키지의 버전을 업데이트 할 수 있도록 해준다. 시스템 업데이트는 필수적이지 않은 패키지는 업데이트하지 않으며, 포테이지 profile에 시스템의 운영과 유지에 필수적이라고 정의된 패키지만을 업데이트한다.
시스템 업데이트를 수행하려면 다음 명령어를 입력하라 :
emerge --update system
포테이지는 여러분이 어떤 패키지들과 버전들을 설치했었고 현재 포테이지 profile에 따라 필요한 것이 무엇인지에 의해 업데이트 버전을 컴파일하고 설치할 것이다. 사용자들은 위의 예제에 옵션 --pretend를 사용해서 이 작업동안 무엇이 설치되고 업그레이드될 지 알 수 있다.
포테이지는 또한 설치된 것 중 필수적이지 않은 패키지를 하나의 명령어로 자동 업그레이드하는 기능을 지원한다. 포테이지 시스템은 패키지들이 충돌을 일으킬 수 있는 버전들을 안전하게 업그레이드 할 수 있을 만큼 지능적으로 만들어져 있다.
포테이지의 world 업데이트는 필요한 패키지를 결정하면서 시스템 프로필, 차단된 패키지 목록(package.mask), world의 profile, profile에 있는 패키지들의 버전 범위를 포함한 의존성(버전 범위들을 포함)을 체크한다. 패키지는는 새로운 버전이 존재하고 world profile에 있거나 혹은 그 의존성과 관계될 때에만 업그레이드 된다. 그리고, 패키지 자체나 혹은 패키지의 해당 버전이 시스템 profile이나 package.mask에 금지되어 있지 않아야 한다.
업그레이드 될 패키지들을 결정할 때, 포테이지는 world profile에 명시된 모든 패키지들을 사용 가능한 최신 버전으로 업그레이드하려 한다. 포테이지는 또한 world profile에 나온 각 패키지의 의존성들을 고려하여 의존 패키지의 상위버전이 존재하고, 의존성에 명시된 버전 범위에 적합하며, 시스템 profile이나 package.mask에 의해 금지된 패키지가 아니라면 업그레이드를 시도할 것이다. 이는 또한 앞에서 언급된 SLOT도 체크한다.
포테이지가 아닌 배포판과 패키징 방식에 익숙한 사용자라면 왜 포테이지가 단순히 버전 번호에만 기초해서 패키지들을 그냥 무작정 업그레이드 하지 않는지(젠투 1.0 이전에 그랬던 것처럼) 혼란스러울 수도 있다. 젠투의 포테이지 트리에 있는 패키지들 중 다수가 사용가능한 여러 개의 버전들을 동시에 가진다. 설치된 패키지와 같은 패키지의 다른 버전은 이에 의존하는 다른 패키지와 맞지 않을 수도 있다.다른 패키지들이 필요로 하는 라이브러리나 툴을 그 호환성을 고려하지 않고 무작정 업그레이드하면 곧바로 많은 문제가 나타날 수 있다. 이를 방지하기 위해 포테이지는 업그레이드시 주의를 기울이고 각 패키지의 ebuild에 정의된 필요사항에 따라 모든 패키지들을 고려한다.
포테이지의 world 업데이트의 핵심은 world profile이다. 대개 개발자들이 정의하고 사용자들은 결코 손대지 않는 시스템 profile과 달리 world의 업데이트 profile은 시간이 지나면서 사용자의 작업에 따라서 간접적으로 생성된다. world profile은 "가장 좋아하는 것들의 목록"과 거의 비슷하다고 보면 된다. emerge로 사용자에 의해 직접 설치된 패키지들은 /var/cache/edb/world에 있는 world 파일에 기록된다. 포테이지는 당신이 패키지를 설치하기 위해 노력했으므로 업데이트에도 관심이 있을 것이라고 가정하고 만들어졌다.
world 파일은 한 줄마다 카테고리와 함께 패키지 이름이 하나씩 적혀있으며 다음과 비슷하게 되어 있을 것이다 :
net-im/gaim net-www/skipstone net-www/galeon app-editors/vim app-text/ispell net-mail/evolution dev-util/ltrace sys-apps/xfsprogs =net-www/mozilla-0.9.8-r3 sys-apps/attr sys-apps/dmapi sys-kernel/linux-sources sys-apps/acl app-office/gnucash app-cdr/xcdroast
이 예제 파일에 있는 패키지들은 거의 대부분 사용자가 어떤 패키지들을 직접 설치할 때 포테이지에 의해 자동으로 추가된다. 이 패키지들은 새로운 버전이 사용 가능하다면 업그레이드 될 수 있다.
주의할만하고 재미있는 입력값은 mozilla 패키지이다(=net-www/mozilla-0.9.8-r3). 이 입력값은 특정한 버전으로 "고정"해놓기 위해 사용자에 의해 수동으로 입력되었다. 패키지 범위는(이 매뉴얼의 패키지 제거절에서 얘기한 것처럼) 포테이지가 패키지를 업데이트 할 때 특정한 버전의 범위만 강제적으로 결정하도록 하기 위해 쓰인다. 이 입력값은 포테이지가 mozilla-0.9.8-r3를 유일한 버전으로 결정하도록 "고정"시키며, 그러므로 world 업데이트동안에도 어떤 이유로든 이 패키지를 업데이트하려고 하지 않을 것이다.
World 업데이트는 다음 명령어로 실행한다 :
emerge --update world
포테이지는 world 파일에 언급된 모든 패키지들을 업데이트하려 할 것이며 필요하면 어떤 의존 패키지라도 업데이트할 것이다. 의존 패키지들은 업그레이드 되는 패키지가 요구하는 가능한 한 가장 최신 버전으로 업그레이드 될 것이다. world에 언급된 패키지가 아니거나 언급된 패키지의 의존성과 상관없는 패키지라면 업데이트 되지 않을 것이다.
world 업데이트 동안에 업데이트 되거나 설치되는 패키지 목록을 보기 위해, 여러분은 이 장의 앞에 설명한 옵션 --pretend를 사용할 수 있다.
World 업데이트가 작동하는 방법중 흥미를 가질만한 부가적인 효과는 시스템에 설치되어 있는 모든 소프트웨어들을 재컴파일하기를 원하는 사용자가 이용할 수 있다. world 업데이트는 world 파일에 언급된 모든 패키지와 그 의존 패키지들을 업데이트하기 때문에 옵션 --emptytree를 쓰면 해당 패키지들과 glibc를 제외한 모든 의존 패키지를 재컴파일 하도록 강제할 수 있다. 이는 컴파일러 옵션이나 USE 키워드 세팅들을 바꾸었을 때 수동으로 모든 패키지들을 재설치할 필요없이 자신이 쓰는 모든 소프트웨어에 그 변화가 적용되기 원하는 사용자들이 유용하게 쓸 수 있다. 간단하게 world 파일에 여러분이 주로 쓰는 모든 어플리케이션을 입력하고 다음 명령어을 실행하라 :
emerge --update world --emptytree
이 작업으로 인해 재컴파일되는 패키지들의 목록을 얻기 위해 명령어에 옵션 --pretend를 추가할 수 있다.
포테이지는 동일한 버전을 다중으로 설치하는 기능을 지원한다. 젠투의 포테이지 트리에는(오래된 어플리케이션은 다른 패키지의 새로운 버전과 호환이 되지 않을 수 있으므로 역호환성을 위해) 이 기능을 사용하는 극소수의 패키지들이 있다.
대개는 패키지의 새로운 버전이 설치될 때 이전 버전은 거의 덮어 씌어지며 일부 문서 파일들과 시스템에 중요하지 않은 파일들만이 남아있다. 시간이 지남에 따라 이 "찌꺼기"들은 쌓이고 유용한 디스크 공간을 낭비할 수 있다.
이 점을 해결하기 위해, 포테이지는 사용자의 시스템에서 이전 버전들의 찌꺼를 제거하기 위한 쉬운 방법을 제공한다. 이 기능은 emerge의 clean 옵션으로 가능하며 다음 명령어로 사용할 수 있다:
emerge clean
emerge는 제거될 패키지의 버전과 개정버전(역주 - r1등으로 표시되는 것) 및 남아 있을 버전들의 목록을 보여주며 사용자에게 Control-C로 취소할 수 있는 시간을 줄 것이다. 포테이지가 아닌 전형적인 시스템이라면 지워지거나 남아 있을 파일들의 목록이 길게 디스플레이 될 것이므로 볼 새도 없이 휙휙 지나가버릴 것이다.
특별히 명시되어 있지 않다면, 포테이지는 world(설치된 모든 패키지들)에 대해 clean을 수행한다고 가정한다. 여러분은 world, system, 패키지 목록, 그리고 이 장의 제거 절에서 언급된 패키지 버전 범위와 같은 옵션으로 범위를 좁힐 수 있다.
어떤 패키지 버전들이 제거되는지 결정할 때 포테이지 시스템은 여러 가지 profile, 설치된 다른 패키지들의 요구조건, 그리고 SLOT 패키지를 고려한다. 모든 패키지들의 의존성들이 정확하다고 가정하고 clean은 이전 패키지 시스템을 안전하게 제거하며 결코 제대로 동작하는 기능을 제거하거나 시스템이 작동하지 못하게 만들지는 않을 것이다.
포테이지는 또한 패키지를 prune하는 것을 지원한다(역주 - prune는 가지치기라는 뜻이지만 원어로 씀). prune은 clean의 불안전한 형태이다. 이것은 가장 마지막으로 설치된 버전을 제외하고 모든 패키지의 모든 버전들을 제거한다. prune은 위의 clean이 검토하는 많은 사항을 검토하지 않으므로 여러분의 시스템에 필수적인 의존 패키지를 제거할 수도 있다. 이 옵션을 사용하면 쉽게 자신들의 시스템이 파괴될 수 있으므로 특별한 상황들을 제외하고는 권장하지 않는다.
prune은 clean의 옵션과 동일하게 쓸 수 있으며 다음과 같이 사용될 수 있다:
emerge prune
젠투 리눅스 배포판의 핵심을 이루는 것중 하나인 포테이지 트리는 상당히 용량이 클 것이다. 명령어 emerge는 따옴표에 들어있는 정규 표현식의 형태로 문자열을 찾을 수 있는 검색 기능을 제공한다. 정규 표현식은 아주 끔찍하게 복잡하기 때문에 여러분이 정규 표현식에 관심이 많다면 이에 대한 좋은 서적을 찾아보기 바란다(역주 : 글쓴이는 정규표현식을 싫어하는 듯... 개인적으로 'Mastering Regular Expressions'을 추천한다 -_-).
대부분의 단순한 검색들은 정규 표현식을 몰라도 가능하다. 다음은 이름이 "gcc"거나 이름에 "gcc"를 포함하는 패키지들을 단순 검색하는 예이다:
emerge search gcc
검색에 해당되는 결과를 찾으면 패키지 이름, 설치 가능한 최신 버전, 설치된 최신 버전, 홈페이지, 패키지에 포함된 소프트웨어의 설명을 보여준다.
emerge가 지원하는 많은 옵션들과 그 작업에 관한 많은 정보는 다음 명령어를 입력해서 찾아볼 수 있다:
emerge --help
편안한 삶을 위한 몇가지 유틸리티들이 젠투 사용자들에 의해 만들어졌다. 이 유틸리티들은 젠투 포테이지 트리의 app-admin/gentoolkit에서 찾을 수 있다.