This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
젠투 리눅스 hppa 핸드북: 포티지 다루기
포티지 파일
설정 지시문
포티지 기본 설정은 /usr/share/portage/config/make.globals에 저장합니다. 모든 포티지 설정은 변수에 저장합니다. 어떤 변수들을 포티지에서 살펴보는지 이들이 나중에 어떤 의미를 지니고 있는지는 나중에 설명하겠습니다.
수많은 설정 지시문이 아키텍처에 따라 다르듯이, 포티지에서는 여러분의 프로파일의 일부로서 기본 설정 파일을 지니고 있습니다. 이 프로파일은 /etc/portage/make.profile 심볼릭 링크를 가리키며, 포티지 설정내용은 여러분의 프로파일의 make.defaults와 모든 상위 프로파일에 있습니다. 앞으로 프로파일과 /etc/portage/make.profile 디렉터리를 설명하겠습니다.
설정 변수를 바꾸려면 /usr/share/portage/config/make.globals 또는 make.defaults를 바꾸지 마십시오. 앞의 두 파일에 우선하는 /etc/portage/make.conf를 대신 활용하십시오. /usr/share/portage/config/make.conf.example에서도 내용을 찾아볼 수 있습니다. 이름으로 의미를 함축한 바와 같이, 이런 경우는 거의 예제 파일일 뿐입니다. 포티지에서는 이 파일을 읽지 않습니다.
포티지 설정 변수를 환경 변수처럼 설정할 수 있지만, 추천하지 않습니다.
프로파일별 정보
이미 앞에서 /etc/portage/make.profile 디렉터리를 언급했습니다. 음, 정확히는 디렉터리는 아니고, 다른 어딘가에 여러분 자신의 프로파일을 만들 수 있다 하더라도 기본적으로 /usr/portage/profiles에 있는 프로파일의 심볼릭 링크이며, 기본 프로파일을 가리킵니다. 이 프로파일 심볼릭 링크는 시스템이 속한 프로파일을 가리킵니다.
프로파일에는 해당 프로파일에 속한 시스템의 꾸러미 목록, 프로파일 상에서 동작하지 않는 (또는 가려놓은) 꾸러미 등과 같은 아키텍처별 포티지 정보를 포함합니다.
사용자별 설정
소프트웨어 설치와 관련한 포티지 동작의 우선 설정이 필요할 때, /etc/portage에 있는 파일을 편집해서 끝낼 수 있습니다. /etc/portage 에 있는 파일 사용을 강력히 권장하며, 웬만하면 환경 변수로 우선 설정하지 마십시오!
/etc/portage에서 다음과 같은 파일을 만들 수 있습니다:
- package.mask : 포티지로 설치하지 말아야 하는 꾸러미 목록 파일
- package.unmask : 젠투 개발자들이 이머징하는 것을 강력히 만류하지만 그래도 설치할 수 있게 하는 꾸러미 목록 파일
- package.accept_keywords : 시스템 또는 아키텍처에서 (아직) 꾸러미를 설치하는데 적당함을 발견하지 못했지만, 그래도 설치할 수 있도록 한 꾸러미 목록
- package.use : 전체 시스템에서 USE 플래그를 사용하도록 제각각의 꾸러미 사용하려는 USE 플래그 목록
이들 요소가 꼭 파일일 필요는 없습니다. 꾸러미 각각에 포함한 단 하나의 파일이어도 됩니다. /etc/portage 디렉터리와 이곳에 만들 수 있는 모든 파일 목록에 대한 더 많은 내용은 포티지 맨페이지에 있습니다.
user $man portage포티지 파일 및 디렉터리 위치 바꾸기
이전에 언급한 설정 파일은 아무데나 저장할 수 없습니다 - 포티지에서는 항상 정확한 위치에서 설정 파일을 찾습니다. 그러나 포티지에서는 다른 위치를 디렉터리를 구성하고, 소스코드를 저장하며, 젠투 저장소 위치로 활용하는 등 다양한 목적으로 활용합니다.
이들 목적은 잘 알려진 기본 위치를 보유하지만 /etc/portage/make.conf에서 개인 취향에 따라 바꿀 수 있습니다. 이 절의 나머지 부분에서는 어떤 특수 목적의 위치를 포티지에서 사용하는지 파일 시스템의 해당 위치를 어떻게 바꾸는지 설명합니다.
이 문서는 단순히 참고서로서의 의미가 아닙니다. 100% 활용하려면 포티지 및 make.conf의 맨 페이지를 참고하십시오.
user $man portage
user $man make.conf파일 저장
젠투 저장소
젠투 저장소의 기본 위치는 /usr/portage 입니다. /usr/share/portage/config/repos.conf의 repos.conf 파일에 지정합니다. 기본 값을 바꾸려면 이 파일을 /etc/portage/repos.conf/gentoo.conf로 복사하고 location 변수값 설정을 바꾸십시오. (변수 값을 바꿔서) 다른 곳에 젠투 저장소를 저장하려면, 바뀐 위치에 따라 /etc/portage/make.profile 심볼릭 링크를 바꿔주는 과정을 잊지 마십시오.
/etc/portage/repos.conf/gentoo.conf의 location 변수 값을 바꾸고 나면, 포티지에서 다룰 /etc/portage/make.conf 파일의 PKGDIR, DISTDIR, RPMDIR 변수값들 역시 바꿔야 합니다.
미리 빌드한 바이너리
기본적으로 포티지에서 미리 빌드한 바이너리를 사용하지 않지만, 이를 위해 더 광범위한 지원을 제공합니다. 포티지에 미리 빌드한 꾸러미로 작업하라고 요청하면, /usr/portage/packages에서 꾸러미를 찾습니다. 이 위치는 PKGDIR 변수에 정의되어 있습니다.
소스 코드
프로그램 소스코드는 기본적으로 /usr/portage/distfiles에 저장합니다. 이 위치는 DISTDIR 변수에 정의합니다.
포티지 데이터베이스
포티지는 (어떤 꾸러미를 설치했는지, 꾸러미에 어떤 파일이 속해있는지 등) 시스템의 상태를 /var/db/pkg에 저장합니다.
이 파일을 직접 수정하지 마십시오! 여러분의 시스템에 대한 포티지의 내부 정보가 깨집니다.
포티지 캐시
포티지 캐시(수정 일시, 가상 꾸러미, 의존성 트리 정보 등)는 /var/cache/edb에 저장합니다. 이 위치는 말 그대로 캐시 입니다. 포티지 관련 프로그램이 돌아가고 있는 잠깐 동안의 상태가 아니라면 이 디렉터리를 비울 수 있습니다.
프로그램 빌드
임시 포티지 파일
포티지 임시 파일은 기본적으로 /var/tmp에 저장합니다. 이는 PORTAGE_TMPDIR 변수에 정의되어 있습니다.
디렉터리 구성
포티지는 이머지할 각각의 꾸러미에 대해 /var/tmp/portage 안에 각각의 빌드 디렉터리를 만듭니다. 이 위치는 BUILD_PREFIX 변수에 지정합니다.
라이브 파일 시스템 위치
기본적으로 포티지는 현재 파일시스템(/)에 모든 파일을 설치하지만, 여러분은 ROOT 환경 변수를 설정하여 위치를 바꿀 수 있습니다. 이는 여러분이 새로운 빌드 이미지를 만들 때 유용합니다.
로깅 기능
Ebuild 로깅
포티지는 각각의 ebuild 에 대해 로그 파일을 만들 수 있지만, PORT_LOGDIR 변수에 설정한 위치가 포티지에서(portage 사용자가) 기록할 수 있을 때 가능합니다. 이 변수는 기본적으로 설정이 되어 있지 않습니다. PORT_LOGDIR을 설정하지 않으면, 새로운 elog로부터 어떤 로그를 받았다 할 지라도 현재 로깅 시스템에서 빌드 로그에 대한 어떤 내용도 받을 수 없습니다.
PORT_LOGDIR 변수를 지정하지 않고 elog를 사용한다면, 아래에서 설명한 바와 같이 빌드 로그와 elog가 저장한 로그를 보실 수 있습니다.
포티지는 elog를 사용하여 세밀한 단위의 기록 기능을 제공합니다:
- PORTAGE_ELOG_CLASSES: 사용자가 어떤 메시지를 기록할 지 설정할 수 있는 변수입니다. 공백으로 구분할 수 있으며, info, warn, error, log, qa가 있습니다.
- info: ebuild가 출력하는 "einfo" 메시지를 기록합니다
- warn: ebuild가 출력하는 "ewarn" 메시지를 기록합니다
- error: ebuild가 출력하는 "eerror" 메시지를 기록합니다
- log: 일부 빌드에서 나타나는 "elog" 메시지를 기록합니다
- qa: ebuild가 출력하는 "QA Notice" 메시지를 기록합니다
- PORTAGE_ELOG_SYSTEM: 로그 메시지를 처리할 모듈을 선택합니다. 비워둔 채로 내버려두면, 로깅을 사용하지 않습니다. 공백으로 구분하여 다음 단어들을 함께 쓸 수 있습니다: save, custom, syslog, mail, save_summary, mail_summary. elog를 사용하려면 최소한 한개 이상의 모듈을 선택해야 합니다.
- save: $PORT_LOGDIR이 정의되지 않았을 경우 $PORT_LOGDIR/elog 또는 /var/log/portage/elog에 각각의 꾸러미에 대한 로그를 저장합니다.
- custom: $PORTAGE_ELOG_COMMAND에 있는 모든 사용자 정의 명령에 메시지를 전달합니다. 다음에 언급될 것입니다.
- syslog: 설치한 시스템 로거로 모든 메시지를 보냅니다.
- mail: $PORTAGE_ELOG_MAILURI에 있는 사용자 정의 메일 서버에 모든 메시지를 전달합니다. 다음에 언급될 것입니다. elog의 메일 기능을 사용하시려면 portage-2.1.1 이상이 필요합니다.
- save_summary: save와 유사하나, $PORT_LOGDIR이 정의되지 않았을 경우 $PORT_LOGDIR/elog/summary.log 또는 /var/log/portage/elog/summary.log에 모든 메시지를 합칩니다.
- mail_summary: mail과 유사하나, emerge를 빠져나갈 때 모든 메시지를 하나의 메일에 작성해서 보냅니다.
- PORTAGE_ELOG_COMMAND: custom 모듈을 활성화했을때만 사용합니다. 로그 메시지를 처리할 명령을 지정하는 곳입니다. 참고로 두가지 변수를 사용하도록 할 수 있습니다. ${PACKAGE}는 꾸러미의 이름과 버전이고, ${LOGFILE}은 로그 파일의 절대 경로입니다. 사용 예는 다음과 같습니다:
PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
- PORTAGE_ELOG_MAILURI: 이 변수에는 주소, 사용자, 암호, 메일서버, 포트 번호와 같은 설정 내용을 포함합니다. 기본 설정은 "root@localhost localhost" 입니다. 다음은, 사용자 이름 및 암호 기반의 인증을 개별적인 포트(기본 포트는 25번입니다)에서 필요로 하는 smtp 서버에 대한 사용 예시 입니다.
PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
- PORTAGE_ELOG_MAILFROM: 로그 메일의 "발신" 주소를 설정하는 변수입니다. 이 변수를 설정하지 않았을 경우 기본값은 "portage"입니다.
- PORTAGE_ELOG_MAILSUBJECT: 로그 메일의 제목 줄을 만들 수 있게 하는 변수입니다. 참고로, 두가지 변수를 사용할 수 있습니다. ${PACKAGE} 에서 꾸러미 이름과 버전을 표시하며, ${HOST}는 포티지가 실행중인 호스트의 완전한 자격을 갖춘 도메인 이름을 표시합니다. 사용 예는 다음과 같습니다:
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"
Portage-2.0.* 의 enotice 사용자는 elog와 호환되지 않는 enotice를 완전히 제거해야합니다.
포티지 설정
앞서 말씀드린 바와 같이 포티지는 /etc/portage/make.conf와 /etc/portage 하위 디렉터리 중 하나에 정의한 수많은 변수로 설정할 수 있습니다. 더욱 많은 완전한 정보를 보시려면 make.conf 와 포티지의 맨 페이지를 참고하십시오.
user $man make.conf
user $man portage빌드 관련 옵션
configure 및 컴파일러 옵션
포티지가 프로그램을 빌드할 때 다음 변수의 내용을 컴파일러와 configure 스크립트에 전달합니다:
- CFLAGS와 CXXFLAGS
- C와 C++ 컴파일시 결정한 컴파일러 플래그를 정의합니다.
- CHOST
- 프로그램 configure 스크립트에 제공할 빌드 호스트 정보를 정의합니다.
- MAKEOPTS
- make 명령에 전달할 내용을 지정하며 보통 컴파일 과정에 사용할 병렬화 처리 가능 갯수를 지정합니다. make 옵션에 대한 더 많은 내용은 make 맨 페이지에서 찾을 수 있습니다.
USE 변수는 configure와 컴파일 과정에서 사용합니다만 이전 장에서 상당히 자세히 설명했습니다.
병합 옵션
포티지가 제각각의 프로그램 제목에 대해 새 버전으로 머지했을 경우, 시스템에 남아있는 오래된 파일을 지울 것입니다. 포티지에서는 이전 버전을 언머징하는데 5초의 기회 시간을 제공합니다. 이 5초라는 값은 CLEAN_DELAY 변수에서 지정합니다.
EMERGE_DEFAULT_OPTS를 설정하면 매번 emerge를 실행할 때마다 지정한 옵션으로 실행할 수 있습니다. 일부 쓸모 있는 옵션으로는 --ask, --verbose, --tree 등이 있습니다.
설정 파일 보호
포티지에서 보호한 위치
포티지는 보호된 위치에 파일을 저장하지 않았을 경우 동일한 소프트웨어 제목을 가진 새 버전에서 제공하는 파일을 덮어씌웁니다. 보호된 위치는 CONFIG_PROTECT 변수에 정의하며 보통 설정 파일 위치가 됩니다. 나열할 디렉터리는 공백으로 구분합니다.
보호한 위치에 기록할 파일은 이름을 바꾸어두며 사용자는 (존재 추정할 수 있는) 설정 파일의 새 버전이 존재함을 포티지가 알려줍니다.
emerge --info 출력에서 현재 CONFIG_PROTECT 설정을 찾아볼 수 있습니다:
user $emerge --info | grep 'CONFIG_PROTECT='포티지 설정 파일 보호에 대한 더 많은 내용은 emerge 맨 페이지의 CONFIGURATION FILES 섹션에 있습니다:
user $man emerge디렉터리 제외
보호된 위치의 각각의 하위 디렉터리를 '보호 해제' 하려면 CONFIG_PROTECT_MASK 변수를 사용할 수 있습니다.
다운로드 옵션
서버 위치
요청된 정보 또는 데이터가 시스템에 없다면, 포티지는 해당 정보를 인터넷으로부터 가져옵니다. 다양한 정보와 데이터 채널에 대한 서버 위치는 다음 변수에 정의합니다:
- GENTOO_MIRRORS
- 소스 코드가 있는 서버 위치의 목록을 정의합니다.
- PORTAGE_BINHOST
- 여러분의 시스템에 대해 미리 빌드한 꾸러미의 각각의 서버 위치를 정의합니다.
세번째 설정은 포티지 트리를 업데이트 할 때 사용하는 rsync 서버의 위치를 포함합니다. 이 설정은 /etc/portage/repos.conf 파일(또는 디렉터리로 정의했다면 디렉터리에 있는 파일)로 정의했습니다:
- sync-type
- 서버 형식을 정의하며 기본은 "rsync"입니다.
- sync-uri
- 포티지가 포티지 트리를 가져올 때 활용할 각각의 서버를 정의합니다.
GENTOO_MIRRORS와 sync-type, sync-uri 변수는 mirrorselect 프로그램에서 자동으로 설정할 수 있습니다. 이 프로그램을 사용할 수 있으려면 app-portage/mirrorselect를 먼저 설치해야 합니다. 더 많은 정보에 대해서는 mirrorselect의 온라인 도움말을 참고하십시오:
root #mirrorselect --help여러분의 환경에서 프록시 서버 사용이 필요하다면, http_proxy, ftp_proxy, RSYNC_PROXY 변수를 사용하여 프록시 서버를 선언할 수 있습니다.
가져오기 명령
포티지에서 소스코드를 가져올 필요가 있을 때, 기본적으로 wget 명령을 사용합니다. FETCHCOMMAND 변수를 통해 이 명령을 바꿀 수 있습니다.
포티지에서는 부분적으로 다운로드한 소스 코드의 나머지 부분도 다시 다운로드 할 수 있습니다. 이 또한 역시 wget 명령을 기본으로 사용하지만 RESUMECOMMAND 변수에서 바꿀 수 있습니다.
FETCHCOMMAND와 RESUMECOMMAND 변수가 올바른 위치에 소스코드를 저장하는지 확인하십시오. 이들 변수 안에 소스 코드 위치와 배포파일 위치를 가리키도록 각각 \${URI}와 \${DISTDIR}를 사용해야 합니다.
FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP 등의 프로토콜별 핸들러도 정의할 수 있습니다.
rsync 설정
포티지 트리를 업데이트할 포티지가 사용하는 rsync 명령을 다른 수단으로 대체할 수 있지만, rsync 명령과 관련된 일부 변수도 설정할 수 있습니다:
- PORTAGE_RSYNC_OPTS
- sync를 진행하는 도중에 사용할 여러가지 기본 변수들을 공백으로 구분하여 설정합니다. 여러분이 정확히 무얼 하고 있는지 알기 전에는 바꾸지 마십시오. 참고로 PORTAGE_RSYNC_OPTS가 비어있을 경우 꼭 필요한 각각의 옵션을 항상 사용합니다.
- PORTAGE_RSYNC_EXTRA_OPTS
- sync를 진행하는 도중에 활용할 추가 옵션을 설정할 때 사용합니다. 각각의 옵션은 공백으로 구분합니다.
--timeout=<number>- 이 숫자는 제한시간처럼 rsync가 연결 상태를 살펴보기 전에 대기할 수 있는 rsync 연결 초 시간을 정의합니다. 이 변수의 기본값은 180이지만 전화걸기 사용자나 느린 컴퓨터를 사용하는 일부 사용자는 300 이상의 값으로 설정합니다.
--exclude-from=/etc/portage/rsync_excludes- 이 변수는 업데이트를 수행하는 동안 무시해야 할 꾸러미나 카테고리의 목록을 담고 있는 파일을 가리킵니다. 이 경우 /etc/portage/rsync_excludes를 가리킵니다.
--quiet- 화면의 출력 내용을 줄입니다.
--verbose- 전체 파일 목록을 출력합니다.
--progress- 각각의 파일에 대한 진행 과정을 표시합니다.
- PORTAGE_RSYNC_RETRIES
- 연결에 성공하기 전에 SYNC 변수에 가리킨 미러로 몇 번에 걸쳐 연결 재시도를 해야 하는지를 정의합니다. 이 변수의 기본값은 3 입니다.
이 옵션을 포함한 더 많은 내용을 알아보시려면 man rsync를 참조하십시오.
젠투 설정
브랜치 선택
ACCEPT_KEYWORDS 변수로 기본 브랜치를 바꿀 수 있습니다. 기본값은 아키텍처의 안정 브랜치입니다. 젠투 브랜치에 대한 더 많은 내용은 다음 장에서 찾아보실 수 있습니다.
포티지 기능
FEATURES 변수로 포티지의 각각의 기능을 활성화 할 수 있습니다. 포티지 기능에 대해서는 이미 이전 장에서 설명했습니다.
포티지 동작
자원 관리
PORTAGE_NICENESS 변수로 포티지 실행에 필요한 nice의 값을 늘리거나 줄일 수 있습니다. PORTAGE_NICENESS값은 현재 nice 값에 추가됩니다.
nice 값에 대한 더 많은 내용을 알아보려면 nice 맨 페이지를 참고하십시오:
user $man nice출력 동작
NOCOLOR 변수의 기본값은 false이며, 포티지의 색상 출력을 끌 지 여부를 설정합니다.
브랜치 한개 사용
안정
ACCEPT_KEYWORDS 변수에는 여러분의 시스템에서 어떤 소프트웨어 브랜치를 사용할 지 정의합니다. 기본값은 hppa와(과) 같은 여러분의 머신 아키텍처에 해당하는 안정 소프트웨어 브랜치입니다.
안정 브랜치 사용 만을 추천합니다. 그러나 안정성에 대해 신경쓰지 않고 https://bugs.gentoo.org로 버그 보고서 제출에 도움을 주고 싶다면, 다음을 계속 읽어내려가십시오.
시험
더 최신의 소프트웨어를 사용하려면 대신 시험 브랜치 사용을 고려해보실 수 있습니다. 포티지가 시험 브랜치를 사용하도록 하려면 여러분 아키텍처 키워드 앞에 ~ 를 붙이십시오.
시험 브랜치는 정확히 말 그대로 시험을 의미합니다. 꾸러미가 시험 중에 있을 경우에는 기능상으론 잘 동작하지만 개발자들이 전체적으로 시험을 하지 않았음을 의미합니다. 이런 경우, 꾸러미에서 버그를 먼저 잘 찾을 수 있으며, 개발자들이 버그 보고서의 내용을 알아챌 수 있도록 게시할 수 있습니다.
하지만 주의해야 할 것은 안정성 문제, 완전하지 않은 꾸러미 처리(잘못된/빠진 의존성), 상당히 빈번한 업데이트(엄청난 양의 빌드 결과물), 깨진 꾸러미가 있음을 알고있어야 합니다. 젠투가 어떤 식으로 동작하고 어떤 식으로 문제를 해결하는지 잘 모른다면, 그냥 안정 브랜치와 시험 브랜치 둘 중 하나를 계속 사용하시는 것이 좋습니다.
예를 들어 hppa 아키텍처에서 시험 브랜치를 하용하려면 /etc/portage/make.conf 를 편집하고 다음을 설정하십시오:
/etc/portage/make.conf시험 브랜치 사용하기ACCEPT_KEYWORDS="~hppa"
안정 브랜치에서 시험 브랜치로 바꾸면, 수많은 꾸러미를 업데이트하는 모습이 나타날 것입니다. 시험 브랜치로 옮겨갔다면, 안정 브랜치로 되돌아가는 일이 도전이 될 수 있음을 상기하십시오.
시험 브랜치와 안정 브랜치 병용
package.accept_keywords
일부 꾸러미는 시험 브랜치를 사용하고 시스템의 일부분에 대해 안정 브랜치를 사용하게끔 포티지에 요청할 수 있습니다. 이렇게 하려면 꾸러미 분류 항목과 사용하려는 시험 브랜치 이름을 /etc/portage/package.accept_keywords에 추가하십시오. (같은 이름으로) 디렉터리를 만들 수 있고, 디렉터리의 파일에 꾸러미를 적어넣을 수 있습니다.
gnumeric을 시험 브랜치에서 사용하려면 다음과 같이 넣습니다:
/etc/portage/package.accept_keywordsgnumeric 프로그램만 시험 브랜치에서 사용하기app-office/gnumeric
각 버전 시험
시험 브랜치에서 지정 소프트웨어 버전을 사용하지만 일부 버전에 대해서는 포티지가 시험 브랜치를 사용하지 못하도록 하려면 package.accept_keywords 위치에 버전을 추가해 넣을 수 있습니다. 이 경우 = 연산자를 사용해야 합니다. <=, <, >, >= 연산자를 사용해서 버전 범위를 넣어줄 수 있습니다.
어떤 경우에는 버전 정보를 추가하면 연산자를 사용해야 합니다. 버전 정보를 제거하면 연산자를 사용할 수 없습니다.
다음 예제를 통해 포티지에 gnumeric-1.2.13을 허용하라고 요청하겠습니다:
/etc/portage/package.accept_keywords선택한 특정 버전 허용=app-office/gnumeric-1.2.13
가린 꾸러미
package.unmask
젠투 개발자들은 가림 해제한 꾸러미를 지원하지 않습니다. 이 부분을 다루신다면 위험이 따릅니다. package.unmask와 package.mask 와 관련된 지원 요청에 대해 답변해드리지 않겠습니다.
젠투 개발자가 꾸러미를 가려놓았는데 package.mask 파일(기본적으로 /usr/portage/profiles)에 이유를 언급했음에도 불구하고 써보고 싶다면, /etc/portage/package.unmask 파일(또는 디렉터리인 경우 디렉터리의 파일)에 사용하고자 하는 꾸러미와 버전(보통 프로파일의 package.mask 파일에 있는 정확히 같은 줄)을 기입하십시오.
예를 들어 =net-mail/hotwayd-0.8이 가려진 상태라면 package.unmask에 정확히 같은 줄을 추가하여 가려진 꾸러미를 원상복귀 할 수 있습니다.
/etc/portage/package.unmask각 package/version 가림 해제=net-mail/hotwayd-0.8
/usr/portage/profiles/package.mask에 꾸러미 버전의 범위가 명시되어 있다면, 여러분은 실제로 원하는 꾸러미의 버전만을 원상복귀해야 합니다. package.unmask에서 버전을 지정하는 방법을 알아보시려면 이전 절을 참고하십시오.
package.mask
포티지가 각각의 꾸러미 또는 꾸러미의 지정 버전을 계정에 취하도록 하기를 원치 않을 경우 /etc/portage/package.mask 위치(파일 또는 해당 파일이 존재하는 디렉터리)에 적당한 줄을 추가하여 꾸러미를 가릴 수 있습니다.
예를 들어 포티지가 gentoo-sources-4.9.16 보다 더 최신의 커널 소스를 설치하지 못하게 하려면, package.mask 위치에 다음 줄을 추가하십시오.
/etc/portage/package.mask4.9.16 보다 큰 버전의 gentoo-sources 가리기>sys-kernel/gentoo-sources-4.9.16
dispatch-conf
dispatch-conf는 ._cfg0000_<name> 파일을 병합할 때 쓰는 보조 도구입니다. ._cfg0000_<name> 파일은 파일을 CONFIG_PROTECT 변수에서 보호한 디렉터리에 덮어쓰려 할 때 포티지에서 만드는 파일입니다.
사용자는 dispatch-conf 프로그램으로 바꾸어놓은 모든 항목의 상태를 유지하며 업데이트를 병합할 수 있습니다. dispatch-conf는 설정 파일의 차이를 패치 형식으로 저장하거나 RCS 리비전 시스템을 사용합니다. 설정 파일을 업데이트할 때 누군가가 실수했을 경우 관리자가 언제든 이전 버전으로 바꿀 수 있음을 의미합니다.
dispatch-conf를 사용할 때 설정 파일을 있는 그대로 유지하거나, 새 설정 파일을 사용하거나, 현재 설정 파일을 편집하거나, 대화식 과정을 통해 바뀐 내용을 합치도록 요청할 수 있습니다. dispatch-conf에는 또한 멋진 일부 추가 기능도 있습니다.
- 최신 주석만 들어있을 경우 업데이트 설정 파일 자동 병합.
- 공백 갯수의 차이만 날 경우에 설정 파일 자동 병합.
/etc/dispatch-conf.conf를 먼저 편집하고 archive-dir 변수가 참조하는 디렉터리를 만드는 과정을 확실히 해두십시오. 다음 dispatch-conf를 실행하십시오.
root #dispatch-confdispatch-conf를 실행할 때 각각 바뀐 설정 파일을 한번에 검토할 수 있습니다. u를 누르면 현재 설정 파일을 새로운 설정 파일로 업데이트(바꾸기)하고 다음 파일로 계속 진행합니다. n을 누르면 dispatch-conf에게 다음 파일로 넘어가라고 지시합니다. 나중에 설정 파일을 병합하도록 그대로 둘 수 있습니다. w를 누르면 새로운 설정 파일을 쳐(지워)내고 다음 파일로 계속 진행합니다. 모든 설정 파일을 다루고 나면, dispatch-conf를 빠져나갑니다. 마찬가지로, 빠져나가려면 언제든지 q를 누를 수 있습니다.
더 많은 내용을 보시려면 dispatch-conf 맨 페이지를 확인하십시오. 여기서는 어떻게 현재 설정 파일과 새로운 설정 파일을 대화형 과정을 통해 합치는지, 새 설정 파일을 어떻게 편집하는지, 파일의 차이점 비교를 어떻게 하는지 등을 알려줍니다.
user $man dispatch-confetc-update
설정 파일을 병합할 다른 도구로 etc-update가 있습니다. dispatch-conf를 사용하는 것처럼 단순하거나, 완전한 기능을 갖추진 않았지만, 대화식 병합 설정 수단을 제공하며 분명하게 바뀐 내용을 자동으로 병합할 수 있습니다.
그러나, dispatch-conf와는 달리, etc-update는 이전 설정 파일을 유지해주지 않습니다. 파일을 업데이트 하고나면 이전 버전은 완전히 날라갑니다! 따라서 이전 설정 파일을 그대로 두고 싶을 때는 dispatch-conf를 사용하기보다는 etc-update를 사용하는 것이 상당히 덜 안전하므로 더욱 조심해야 합니다.
root #etc-update간단하게 바뀐 내용을 병합하고 나면, 업데이트를 기다리는 보호 파일의 목록이 나타납니다. 아래에 선택할 수 있는 옵션이 있습니다:
Please select a file to edit by entering the corresponding number.
(-1 to exit) (-3 to auto merge all remaining files)
(-5 to auto-merge AND not use 'mv -i'):-1을 입력하면, etc-update는 더 이상의 바뀐 내용으로 계속 진행하지 않고 빠져나갑니다. -3이나 -5를 입력하면 나열한 모든 설정 파일을 새 버전으로 덮어씁니다. 따라서 자동으로 업데이트 하지 않을 설정 파일을 먼저 선택하는 것이 매우 중요합니다. 나열된 나머지 설정 파일에 대해 숫자를 입력하는 것은 단순한 문제입니다.
예제에서는 /etc/pear.conf 설정 파일을 선택합니다:
Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf [...] End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf (1) Replace original with update (2) Delete update, keeping original as is (3) Interactively merge original with update (4) Show differences again
이제 두 파일의 차이점을 보실 수 있습니다. 최신 설정 파일을 문제 없이 사용할 수 있을 거라고 믿는다면 1을 입력하십시오. 최신 설정 파일이 필요하지 않다고 믿거나 더이상 새롭거나 쓸모있는 정보가 없다면 2를 입력하십시오. 현재 설정 파일을 대화식 과정을 통해 업데이트 하려면 3을 입력하십시오.
대화식 병합 방법에 대해 여기서 더 자세하게 설명할 거리가 없습니다. 설명에 완벽을 기하기 위해 두 파일을 대화식으로 병합하는 동안 사용할 수 있는 명령을 보여드리겠습니다. 두 줄(원본 및 새로운 제안)의 내용이 뜨며, 다음 명령 중 하나를 입력할 수 있는 질문이 나타납니다:
ed: Edit then use both versions, each decorated with a header. eb: Edit then use both versions. el: Edit then use the left version. er: Edit then use the right version. e: Edit a new version. l: Use the left version. r: Use the right version. s: Silently include common lines. v: Verbosely include common lines. q: Quit.
중요한 설정 파일의 업데이트를 끝내면 이제 나머지 다른 설정 파일을 자동으로 업데이트 할 수 있습니다. 더 이상 업데이트 할 수 있는 설정 파일을 찾을 수 없으면 etc-update가 끝납니다.
quickpkg
quickpkg를 통해 시스템에 이미 병합한 꾸러미의 아카이브를 만들 수 있습니다. 이 아카이브는 미리 빌드한 꾸러미로 사용할 수 있습니다. quickpkg 실행은 간단합니다. 아카이브를 만들려는 꾸러미의 이름을 추가하기만 하십시오.
curl, orage, procps를 아카이빙하려면:
root #quickpkg curl orage procps미리 빌드한 꾸러미는 $PKGDIR(기본 위치는 /usr/portage/packages/)에 저장합니다. 이 꾸러미는 $PKGDIR/CATEGORY 에 있습니다.
젠투 저장소 하위 세트 활용
꾸러미 및 분류 항목 제외
각각의 분류 항목/꾸러미를 선택적으로 업데이트 할 수 있으며 다른 분류 항목/꾸러미를 무시할 수 있습니다. rsync로 emerge --sync 단계를 수행하는 동안 각각의 분류 항목/꾸러미를 제외하여 처리할 수 있습니다.
/etc/portage/make.conf의 PORTAGE_RSYNC_EXTRA_OPTS 변수에 제외할 패턴이 담긴 파일 이름을 정의해야 합니다.
/etc/portage/make.conf제외 파일 지정PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
/etc/portage/rsync_excludes모든 게임 제외games-*/*
하지만, 허용한 새로운 꾸러미 일부가 제외한 새로운 꾸러미에 의존하는 문제가 있을 수 있음을 참고하십시오.
비공식 ebuild 추가
개별 저장소 지정
젠투 저장소에 공식적으로 존재하지 않는 ebuild를 사용하도록 포티지에 요청할 수 있습니다. 서드파티 ebuild를 저장할 새 디렉터리(예를 들어 /usr/local/portage)를 만드십시오. 공식 젠투 저장소와 같은 디렉터리 구조를 사용하십시오!
root #mkdir -p /usr/local/portage/{metadata,profiles}
root #chown -R portage:portage /usr/local/portage다음 저장소를 알아볼 수 있는 이름을 지으십시오. 다음 예제에서는 저장소 이름을 "localrepo"로 사용합니다:
root #echo 'localrepo' > /usr/local/portage/profiles/repo_name포티지에 master 저장소를 주 젠투 저장소로, 해당 저장소를 자동으로 동기화하지 않게하겠습니다(rsync 서버, git 미러 또는 다른 저장소 공급원으로 받쳐주지 않았기 때문):
/usr/local/portage/metadata/layout.confmasters = gentoo auto-sync = false
마지막으로, 로컬 저장소를 찾을 수 있는 위치를 포티지에 알리는 /etc/portage/repos.conf 파일에 저장소 설정 파일을 만들어 로컬 파일 시스템의 저장소를 활성화하겠습니다.
/etc/portage/repos.conf/localrepo.conf[localrepo] location = /usr/local/portage
다양한 오버레이 다루기
다양한 소스로부터 비공식 ebuild를 사용하려 하거나, 젠투 저장소에 올려놓기 전 꾸러미를 테스트하거나, 다양한 오버레이를 개발하는 고급 사용자를 위해 app-portage/layman 꾸러미에서 최신의 오버레이 저장소를 유지하도록 도와주는 도구인 layman을 제공합니다.
Alternatively, install app-eselect/eselect-repository to utilize the native synchronization in Portage. See also Eselect/Repository
eselect-repository
Adding repositories is simple with this tool.
For instance, to enable the hardened-development overlay:
root #eselect repository enable hardened-developmentUpdating of overlays added with this methods happens naturally with:
root #emerge --sync일단 먼저 설치하고 오버레이 사용자 안내서en에서 안내하는 대로 layman을 설정하신 다음, layman -a명령으로 사용하려는 저장소를 추가하십시오.
hardened-development 오버레이를 활성화하려면:
root #layman -a hardened-developmentlayman을 통해 사용하는 저장소의 수와는 상관없이, 모든 저장소를 다음 명령으로 업데이트할 수 있습니다:
root #layman -S오버레이를 다루는 내용을 더 많이 찾아보시려면 man layman를 읽어보시고 이전에 연결해둔 layman/overlay 사용자 안내서를 읽어보십시오.
포티지에서 관리하지 않는 프로그램
자체 관리 프로그램으로 포티지 사용
Sometimes users want to configure, install and maintain software individually without having Portage automate the process, even though Portage can provide the software titles. Known cases are kernel sources and Nvidia drivers. It is possible to configure Portage so it knows that a certain package is manually installed on the system (and thus take this information into account when calculating dependencies). This process is called injecting and is supported by Portage through the /etc/portage/profile/package.provided file.
For instance, to inform Portage about gentoo-sources-4.9.16 which has been installed manually, add the following line to /etc/portage/profile/package.provided:
/etc/portage/profile/package.providedMarking gentoo-sources-4.9.16 as manually installedsys-kernel/gentoo-sources-4.9.16
This is a file that uses versions without an
= operator.
도입부
대부분의 사용자들에게 지금까지 전달한 정보는 그들의 전체적인 리눅스 활용 측면에 있어 충분합니다. 하지만 포티지는 좀 더 방대합니다. 포티지의 대부분의 기능은 고급 사용자를 위한 것들이거나 특정 일부의 경우에만 활용할 수 있습니다. 고로, 이런 경우들에 대해 문서화하지 않는 것이 전혀 실례가 되지 않습니다.
물론 수많은 유연성은 상당한 잠재적 경우의 수를 수반하기도 합니다. 그들 모두를 이곳에 문서화할 수는 없습니다. 대신 여러분의 필요에 맞추기 위해 여러분이 좀 더 자세를 낮춰서 볼 수 있는 일부 일반적인 문제들에 초점을 맞추려 합니다. 좀 더 특별한 꼼수나 요령은 젠투 위키에서 찾아볼 수 있습니다.
이런 경우가 아니라면 대부분, 포티지에서 제공하는 메뉴얼 페이지를 깊게 파고들면 이러한 추가 기능들에 대해 찾아보실 수 있습니다.
user $man portage
user $man make.conf
결국 제대로 동작하지 않는 상황에서 고급 기능을 알아내면 디버깅을 할 수 있게 해주며 상당히 어려운 문제해결이 가능합니다. 버그를 직면하여 버그 보고서를 제출하려 한다면 이들 사항에 주의를 기울였는지 확인해보십시오.
꾸러미별 환경 변수
/etc/portage/env 사용
기본적으로 꾸러미 빌드시 /etc/portage/make.conf에 정의된 CFLAGS, MAKEOPTS 등과 같은 환경 변수를 사용합니다. 일부의 경우 각각의 지정한 꾸러미에 대해 다른 변수를 제공합니다. 이렇게 하기 위해 포티지에서는 /etc/portage/env와 /etc/portage/package.env의 사용을 지원합니다.
/etc/portage/package.env파일에는 여러분이 뭘 바꾸려는지 포티지에 알려줄 특정 식별자와, 이 식별자를 벗어난 변수들의 꾸러미 목록이 있습니다. 여러분이 직접 선택한 식별자 이름을 포티지가 해당 변수에 대한 내용을 /etc/portage/env/IDENTIFIER 파일에서 찾아봅니다.
예제: 개별 꾸러미 디버그하기
예제를 통해 media-video/mplayer 꾸러미에 대한 디버깅을 활성화 하겠습니다.
제일 먼저 /etc/portage/env/debug-cflags 파일에서 디버깅 변수를 설정하겠습니다. 이름은 임의대로 정했지만, 물론 이름을 임의대로 지은 이유를 더욱 명확하게 하기위해 이유를 반영하겠습니다.
/etc/portage/env/debug-cflags디버깅용 변수CFLAGS="-O2 -ggdb -pipe" FEATURES="${FEATURES} nostrip"
그 다음 이 내용을 사용하기 위해 media-video/mplayer 꾸러미 태그를 넣겠습니다.
/etc/portage/package.envmplayer 꾸러미에 debug-cflags 사용하기media-video/mplayer debug-cflags
이머지 프로세스 후킹
/etc/portage/bashrc 및 관련 파일 사용
포티지가 ebuild와 동작할 때, (src_prepare, src_configure, pkg-postinst 등과 같은) 다양한 빌드 함수를 호출하는 배시 환경을 사용합니다. 그러나 또한 포티지는 여러분 자신이 배시 환경을 설정할 수 있도록 합니다.
배시 환경을 사용의 잇점은 각각의 단계 과정이 실행하고 있는 동안 emerge 프로세스를 훅킹(동작 가로채기)할 수 있다는 점입니다. 이는 항상 (/etc/portage/bashrc 를 통해) emerge 또는 (이전에 설명한 바와 같이 /etc/portage/env를 통해) 꾸러미별 환경을 사용하여 처리할 수 있습니다.
프로세스를 후킹하려면 배시 환경에서는 이빌드 개발을 진행하는 동안 언제든 사용할 수 있는 변수 (P, PF 등)처럼 EBUILD_PHASE, CATEGORY 변수를 매번 확인해볼 수 있습니다. 이들 변수 값을 기반으로 추가적인 절차를 실행할 수 있습니다.
예제: 파일 데이터베이스 업데이트
이 예제에서는 시스템의 데이터베이스가 최신인지 확인하기 위해 일부 파일 데이터베이스 프로그램을 호출하려 /etc/portage/bashrc를 사용하겠습니다. 사용할 수 있는 프로그램의 예로 aide(침입 탐지 도구)와 updatedb(mlocate와 함께 사용)를 들 수 있지만 이 프로그램이 예제를 의미하는 것은 아닙니다. AIDE에 대한 도움말이라고 착각하지 마십시오 ;-)
이 경우에 대해 /etc/portage/bashrc를 활용하려면 파일 시스템의 파일이 바뀌기 때문에 postrm(파일을 다 지운 후)과 postinst(파일 설치 후)에서 "후킹"을 진행해야 합니다.
/etc/portage/bashrcpostinst와 postrm 단계 후킹if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ]; then echo ":: Calling aide --update to update its database" aide --update echo ":: Calling updatedb to update its database" updatedb fi
--sync 후 작업 실행
/etc/portage/postsync.d 위치 사용
지금까지 ebuild 프로세스에서의 후킹에 대해 이야기해왔습니다. 하지만 이 말고도 또 다른 중요한 기능은 젠투 저장소 업데이트입니다. 젠투 저장소를 업데이트 하고 나서 작업을 실행하려면 /etc/portage/postsync.d에 스크립트를 넣고 이 스크립트를 실행 가능한 상태로 설정했는지 확인하십시오.
예제: eix-update 실행
트리를 업데이트 하려고 eix-sync를 사용하지 않았다면 /etc/portage/postsync.d에 /usr/bin/eix에 연결한 eix-update 심볼릭 링크를 위치시켜서, emerge --sync (또는 emerge-websync)를 실행한 후 업데이트한 데이터베이스를 계속 유지할 수 있습니다.
root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update다른 이름을 사용하고자 한다면 usr/bin/eix-update를 대신 호출하는 스크립트가 필요합니다. eix 바이너리는 실행한 기능을 찾기 위해 어떻게 호출되었는지 찾아봅니다. eix-update라고 하는 eix 심볼릭 링크를 놓지 않으면 제대로 동작하지 않습니다.
프로파일 설정 중복 적용
/etc/portage/profile 사용
기본적으로 젠투는 etc/portage/make.profile (적절한 디렉터리로의 심볼릭 링크) 이 가리키는 프로파일에 들어있는 설정을 사용합니다. 이 프로파일은 다른 프로파일(parent 파일을 통해)로부터 상속받는 설정과 특정 환경에서의 설정을 정의합니다.
/etc/portage/profile을 사용하여 꾸러미(어떤 꾸러미를 시스템 셋의 일부로 간주하는지)와 같은 프로파일 설정을 덮어씌울 수 있으며 USE 플래그를 강제할 수 있는 등의 설정을 할 수 있습니다.
예제: 시스템 셋에 nfs-utils 추가
상당히 중요한 파일 시스템으로 NFS 기반 파일 시스템을 사용한다면, net-fs/nfs-utils 꾸러미를 지우려고 할 때 시스템 꾸러미로 표시한 이 꾸러미가 필요하기 때문에, 포티지가 관리자에게 강력히 경고합니다.
이를 진행하기 위해 /etc/portage/profile/packages에 * 기호를 앞에 붙인 꾸러미 이름을 추가합니다:
/etc/portage/profile/packagesnfs-utils을 시스템 꾸러미로 추가*net-fs/nfs-utils
비표준 패치 적용
epatch_user 사용
epatch_user 함수는 EAPI 5 이하에서 동작합니다. EAPI 6 이상에서는 eapply_user 함수를 참고하십시오.유사한 방법으로 수많은 이빌드를 관리하기 위해 이빌드 개발자들은 일반적으로 사용하는 함수들을 정의한 eclass(쉘 라이브러리의 한 종류)를 사용합니다. eclass 중 하나로 쓸만한 epatch_user 함수를 제공하는 eutils.eclass가 있습니다.
epatch_user 함수는 우선적으로 발견한 어떤 디렉터리에서든지 /etc/portage/patches/<category>/<package>[-<version>[-<revision>]] 에 있는 소스코드 패치를 적용합니다. 아쉽게도 모든 ebuild가 이 함수를 자동으로 호출하지 않기 때문에 이 위치에 패치를 위치시키는 것만으론 항상 동작하지 않습니다.
다행스럽게도, prepare 과정과 같은 경우라면 위에서 언급한 정보를 제공하였을 때 후킹으로 함수를 호출할 수 있습니다. 이 함수는 원하는 만큼 호출할 수 있는데, 패치는 한번만 적용합니다.
예제: Firefox에 패치 적용
www-client/firefox 꾸러미는 이빌드에서 epatch_user를 호출하는 드문 꾸러미중 하나입니다. 따라서 다른 특별한 어떤 것도 설정을 덮어쓸 필요가 없습니다.
Firefox를 패치하려면 (예를 들어 개발자가 여러분께 Firefox를 패치와 함께 제공하려 하고 여러분이 보고한 버그가 패치되었는지 확인차 질문하는 경우) /etc/portage/patches/www-client/firefox 에 패치를 복사하고 (아마도 이후 버전과 혼동되지 않게 하려면 버전을 포함하여 완전한 이름을 사용하는 것이 가장 좋을지도 모릅니다) Firefox를 다시 빌드합니다.
Warning: Display title "젠투 리눅스 hppa 핸드북: 포티지 다루기" overrides earlier display title "Handbook:HPPA/Full/Portage/ko".