"Trans:GentooX86Handbook3-6"의 두 판 사이의 차이

Gentoo Korea Wiki
둘러보기로 가기 검색하러 가기
 
(같은 사용자의 중간 판 2개는 보이지 않습니다)
66번째 줄: 66번째 줄:
  
 
==== 예제: nfs-utils를 시스템 셋에 추가하기 ====
 
==== 예제: nfs-utils를 시스템 셋에 추가하기 ====
 +
상당히 중요한 파일 시스템으로서 NFS 기반 파일을 사용한다면, 지우려고 할 때 포티지에서 강력하게 경고하는 시스템 패키지로서 "보호된" net-fs/nfs-utils 패키지를 설치하려 할 것입니다.
  
 +
이를 진행하기 위해 /etc/portage/profile/packages에 패키지를 {{blue|*}} 기호를 앞에 붙여 추가합니다.
 +
 +
{{Example|코드 예제 5.1: /etc/portage/profile/packages 내용|*net-fs/nfs-utils}}
  
 
=== 비표준 패치 적용하기 ===
 
=== 비표준 패치 적용하기 ===
 +
==== epatch_user 사용하기 ====
 +
유사한 방법으로 수많은 ebuild를 관리하기 위해 ebuild 개발자들은 일반적으로 사용하는 함수들을 정의한 ''eclass''(쉘 라이브러리의 한 종류)를 사용합니다. eclass 중 하나로 {{blue|epatch_user}} 라는 흥미로운 함수를 제공하는 eutils.eclass가 있습니다.
 +
 +
{{blue|epatch_user}} 함수는 우선적으로 발견한 어떤 디렉터리에서든지간에 /etc/portage/patches/<category>/<package>[-<version>[-<revision>]] 에 있는 소스코드 패치를 적용합니다. 아쉽게도 모든 ebuild가 이 함수를 자동으로 호출하지 않기 때문에 이 위치에 패치를 위치시키는 것 만으론 항상 동작하지 않습니다.
 +
 +
다행스럽게도,  {{blue|prepare}} 과정과 같은 경우라면 위에서 언급한 정보를 제공하였을 때 훅킹을 통해 함수를 호출할 수 있습니다. 이 함수는 원하는 만금 호출할 수 있는데, 패치는 한번만 적용합니다.
 +
 +
==== 예제: 파이어폭스에 패치 적용하기 ====
 +
www-client/firefox 패키지는 ebuild에서 {{blue|epatch_user}}를 호출하는 드문 패키들중 하나입니다. 따라서 다른 특별한 어떤 것도 설정을 덮어씌울 필요가 없습니다.
 +
 +
firefox를 패치하려 한다면 (예를 들어 개발자가 여러분께 firefox를 패치와 함께 제공하려 하고 여러분이 보고한 버그가 패치되었는지 확인차 질문하는 경우) /etc/portage/patches/www-client/firefox 에 패치를 복사하고 (아마도 이후 버전과 혼동되지 않게 하려면 버전을 포함하여 완전한 이름을 사용하는 것이 가장 좋을 것입니다) firefox를 다시 빌드합니다.
 +
 +
[[Category:GentooTrans]]

2013년 3월 27일 (수) 20:31 기준 최신판

고급 포티지 기능

개요

대부분의 사용자들에게 지금까지 전달한 정보는 그들의 전체적인 리눅스 활용 측면에 있어 충분합니다. 하지만 포티지는 좀 더 방대합니다. 포티지의 대부분의 기능은 고급 사용자를 위한 것들이거나 특정 일부의 경우에만 활용할 수 있습니다. 고로, 이런 경우들에 대해 문서화하지 않는 것이 전혀 실례가 되지 않을 것입니다.

물론 수많은 유연성은 엄청나게 많은 잠재적 경우의 수를 수반하기도 합니다. 그들 모두를 이곳에 문서화할 수는 없습니다. 대신 여러분의 필요에 맞추기 위해 여러분이 좀 더 자세를 낮춰서 볼 수 있는 일부 일반적인 문제들에 초점을 맞추려 합니다. 좀 더 특별한 꼼수나 요령이 필요하다면 여기 대신 젠투 위키에서 찾아보십시오.

이런 경우가 아니라면 대부분, 포티지에서 제공하는 메뉴얼 페이지를 깊게 파고들면 이러한 추가 기능들에 대해 찾아보실 수 있습니다.


코드 예제 1.1: 포티지 맨 페이지 보기
$ man portage
$ 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/<식별자> 파일에서 찾아볼 것입니다.

예제: 특정 패키지에 디버깅 사용하기

예제를 통해 media-video/mplayer 패키지에 대해 디버깅을 활성화 하겠습니다.

제일 먼저 /etc/portage/env/debug-cflags 파일에서 디버깅 변수를 설정하겠습니다. 이름은 임의대로 정했지만, 물론 왜 임의대로 지은 이름을 넣는지에 대해 더욱 명확하게 하기 위해 임의 대로 지은 이름의 이유를 반영하겠습니다.


코드 예제 2.1: /etc/portage/env/debug-cflags 내용
CRLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"


그 다음 이 내용을 사용하기 위해 media-video/mplayer 패키지 태그를 넣겠습니다.


코드 예제 2.2: /etc/portage/package.env 내용
media-video/mplayer debug-cflags


이머지 과정 훅킹하기(동작 가로채기)

/etc/portage/bashrc와 관련 파일 사용하기

포티지가 ebuild를 가지고 동작할 때, (src_prepare, src_configure, pkg-postinst 등과 같은) 다양한 빌드 함수를 호출하는 배시 환경을 사용합니다. 그러나 또한 포티지는 여러분 자신이 배시 환경을 설정할 수 있도록 합니다.

여러분의 배시 환경을 사용하는 것에 대한 잇점은 각각의 단계 과정이 실행하고 있는 동안 emerge 프로세스를 훅킹(동작 가로채기)할 수 있다는 것입니다. 이는 항상 (/etc/portage/bashrc 를 통해) emerge 또는 (이전에 설명한 바와 같이 /etc/portage/env를 통해) 패키지별 환경을 사용하여 수행할 수 있습니다.

프로세스를 훅킹하려면 배시 환경에서는 ebuild 개발을 수행하는 동안 항상 사용할 수 있는 변수 (P, PF 등)처럼 EBUILD_PHASE, CATEGORY 변수를 매번 확인해볼 수 있습니다. 이들 변수 값을 기반으로 추가적인 절차를 실행할 수 있습니다.

예제: 파일 데이터베이스 업데이트

이 예제에서는 시스템의 데이터베이스가 최신인지 확인하기 위해 일부 파일 데이터베이스 프로그램을 호출하려 /etc/portage/bashrc를 사용하겠습니다. 사용할 수 있는 프로그램의 예로 aide (침입 탐지 도구)와 updatedb (locate와 함께 사용함)를 들 수 있지만 이 프로그램이 예제를 의미하는 것은 아닙니다. AIDE에 대한 도움말이라고 착각하지 마십시오 ;-P

이 경우 /etc/portage/bashrc를 사용하려면 postrm(파일을 다 지운 후)과 postinst(파일 설치 후)에서 "훅킹"을 수행해야 하는데 파일 시스템의 파일이 바뀌기 때문입니다.


코드 예제 3.1: /etc/portage/bashrc 예제
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를 실행한 후 업데이트한 데이터베이스를 계속 지닐 수 있습니다.


코드 예제 4.1: sync 동작 수행 후 eix-update 실행하기
# 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에 패키지를 * 기호를 앞에 붙여 추가합니다.


코드 예제 5.1: /etc/portage/profile/packages 내용
*net-fs/nfs-utils


비표준 패치 적용하기

epatch_user 사용하기

유사한 방법으로 수많은 ebuild를 관리하기 위해 ebuild 개발자들은 일반적으로 사용하는 함수들을 정의한 eclass(쉘 라이브러리의 한 종류)를 사용합니다. eclass 중 하나로 epatch_user 라는 흥미로운 함수를 제공하는 eutils.eclass가 있습니다.

epatch_user 함수는 우선적으로 발견한 어떤 디렉터리에서든지간에 /etc/portage/patches/<category>/<package>[-<version>[-<revision>]] 에 있는 소스코드 패치를 적용합니다. 아쉽게도 모든 ebuild가 이 함수를 자동으로 호출하지 않기 때문에 이 위치에 패치를 위치시키는 것 만으론 항상 동작하지 않습니다.

다행스럽게도, prepare 과정과 같은 경우라면 위에서 언급한 정보를 제공하였을 때 훅킹을 통해 함수를 호출할 수 있습니다. 이 함수는 원하는 만금 호출할 수 있는데, 패치는 한번만 적용합니다.

예제: 파이어폭스에 패치 적용하기

www-client/firefox 패키지는 ebuild에서 epatch_user를 호출하는 드문 패키들중 하나입니다. 따라서 다른 특별한 어떤 것도 설정을 덮어씌울 필요가 없습니다.

firefox를 패치하려 한다면 (예를 들어 개발자가 여러분께 firefox를 패치와 함께 제공하려 하고 여러분이 보고한 버그가 패치되었는지 확인차 질문하는 경우) /etc/portage/patches/www-client/firefox 에 패치를 복사하고 (아마도 이후 버전과 혼동되지 않게 하려면 버전을 포함하여 완전한 이름을 사용하는 것이 가장 좋을 것입니다) firefox를 다시 빌드합니다.