Handbook:Parts/Portage/Advanced/ko

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

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

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

결국 제대로 동작하지 않는 상황에서 고급 기능을 알아내면 디버깅을 할 수 있게 해주며 상당히 어려운 문제해결이 가능합니다. 버그를 직면하여 버그 보고서를 제출하려 한다면 이들 사항에 주의를 기울였는지 확인해보십시오.

/etc/portage/env 사용
기본적으로 패키지 빌드시 에 정의된 CFLAGS, MAKEOPTS 등과 같은 환경 변수를 사용합니다. 일부의 경우 여러분들은 각각의 지정된 패키지에 대해 다른 변수들을 제공하려 할 것입니다. 이렇게 하기 위해 포티지에서는 와 의 사용을 지원합니다.

파일에는 여러분이 뭘 바꾸려는지 포티지에 알려줄 특정 식별자와, 이 식별자를 벗어난 변수들의 패키지 목록이 있습니다. 여러분이 직접 선택한 식별자 이름을 포티지가 해당 변수에 대한 내용을 파일에서 찾아봅니다.

예제: 개별 꾸러미 디버그하기
예제를 통해 패키지에 대한 디버깅을 활성화 하겠습니다.

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

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

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

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

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

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

이 경우에 대해 를 활용하려면 파일 시스템의 파일이 바뀌기 때문에 postrm(파일을 다 지운 후)과 postinst(파일 설치 후)에서 "후킹"을 진행해야 합니다.

/etc/portage/postsync.d 위치 사용
지금까지 ebuild 프로세스에서의 훅킹에 대해 이야기해왔습니다. 하지만 이 말고도 또 다른 중요한 기능이 있습니다. 포티지 트리를 업데이트 하는 것입니다. 포티지 트리를 업데이트 하고 나서 작업을 실행하려면 에 스크립트를 넣고 이 스크립트를 실행 가능한 상태로 놓았는지 확인하십시오.

예제: eix-update 실행
트리를 업데이트 하려고 를 사용하지 않았다면 에 에 연결한  심볼릭 링크를 위치시켜서,   (또는  )를 실행한 후 업데이트한 데이터베이스를 계속 유지할 수 있습니다.

/etc/portage/profile 사용
기본적으로 젠투는 (적절한 디렉터리로의 심볼릭 링크) 이 가리키는 프로파일에 들어있는 설정을 사용합니다. 이 프로파일은 다른 프로파일(parent 파일을 통해)로부터 상속받는 설정과 특정 환경에서의 설정을 정의합니다.

을 사용하여 패키지 (어떤 패키지가 시스템 셋의 일부로 간주되는지) 와 같은 프로파일 설정을 덮어씌울 수 있으며 USE 플래그를 강제할 수 있는 등의 설정을 할 수 있습니다.

예제: 시스템 셋에 nfs-utils 추가
상당히 중요한 파일 시스템으로서 NFS 기반 파일 시스템을 사용한다면, 패키지를 지우려고 할 때 시스템 패키지로 표시한 이 패키지가 필요하여 포티지에서 관리자에게 강력히 경고할 것입니다.

이를 진행하기 위해 /etc/portage/profile/packages에 패키지를 * 기호를 앞에 붙여 추가합니다:

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

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

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

예제: Firefox에 패치 적용
꾸러미는 ebuild에서 epatch_user를 호출하는 드문 꾸러미중 하나입니다. 따라서 다른 특별한 어떤 것도 설정을 덮어쓸 필요가 없습니다.

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