Handbook:Parts/Portage/Advanced/ko
도입부
대부분의 사용자들에게 지금까지 전달한 정보는 그들의 전체적인 리눅스 활용 측면에 있어 충분합니다. 하지만 포티지는 좀 더 방대합니다. 포티지의 대부분의 기능은 고급 사용자를 위한 것들이거나 특정 일부의 경우에만 활용할 수 있습니다. 고로, 이런 경우들에 대해 문서화하지 않는 것이 전혀 실례가 되지 않습니다.
물론 수많은 유연성은 상당한 잠재적 경우의 수를 수반하기도 합니다. 그들 모두를 이곳에 문서화할 수는 없습니다. 대신 여러분의 필요에 맞추기 위해 여러분이 좀 더 자세를 낮춰서 볼 수 있는 일부 일반적인 문제들에 초점을 맞추려 합니다. 좀 더 특별한 꼼수나 요령은 젠투 위키에서 찾아볼 수 있습니다.
이런 경우가 아니라면 대부분, 포티지에서 제공하는 메뉴얼 페이지를 깊게 파고들면 이러한 추가 기능들에 대해 찾아보실 수 있습니다.
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 파일에서 디버깅 변수를 설정하겠습니다. 이름은 임의대로 정했지만, 물론 이름을 임의대로 지은 이유를 더욱 명확하게 하기위해 이유를 반영하겠습니다.
root #
mkdir /etc/portage/env
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
그 다음 이 내용을 사용하기 위해 media-video/mplayer 꾸러미 태그를 넣겠습니다.
media-video/mplayer debug-cflags
이머지 프로세스 후킹
/etc/portage/bashrc 및 관련 파일 사용
포티지가 ebuild와 동작할 때, (src_prepare
, src_configure
, pkg-postinst
등과 같은) 다양한 빌드 함수를 호출하는 배시 환경을 사용합니다. 그러나 또한 포티지는 여러분 자신이 배시 환경을 설정할 수 있도록 합니다.
배시 환경을 사용의 잇점은 각각의 단계 과정이 실행하고 있는 동안 emerge 프로세스를 훅킹(동작 가로채기)할 수 있다는 점입니다. 이는 항상 (/etc/portage/bashrc 를 통해) emerge 또는 (이전에 설명한 바와 같이 /etc/portage/env를 통해) 꾸러미별 환경을 사용하여 처리할 수 있습니다.
Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name
and post_phase_name
. For example, Portage will call the post_pkg_postinst
hook just after calling the pkg_postinst
phase function.
프로세스를 후킹하려면 배시 환경에서는 이빌드 개발을 진행하는 동안 언제든 사용할 수 있는 변수 (P, PF 등)처럼 EBUILD_PHASE, CATEGORY 변수를 매번 확인해볼 수 있습니다. 이들 변수 값을 기반으로 추가적인 절차를 실행할 수 있습니다.
예제: 파일 데이터베이스 업데이트
이 예제에서는 시스템의 데이터베이스가 최신인지 확인하기 위해 일부 파일 데이터베이스 프로그램을 호출하려 /etc/portage/bashrc를 사용하겠습니다. 사용할 수 있는 프로그램의 예로 aide(침입 탐지 도구)와 updatedb(mlocate와 함께 사용)를 들 수 있지만 이 프로그램이 예제를 의미하는 것은 아닙니다. AIDE에 대한 도움말이라고 착각하지 마십시오 ;-)
이 경우에 대해 /etc/portage/bashrc를 활용하려면 파일 시스템의 파일이 바뀌기 때문에 postrm
(파일을 다 지운 후)과 postinst
(파일 설치 후)에서 "후킹"을 진행해야 합니다.
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
post_pkg_postinst() { my_database_update; } post_pkg_postrm() { my_database_update; } }}
--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에 *
기호를 앞에 붙인 꾸러미 이름을 추가합니다:
*net-fs/nfs-utils
비표준 패치 적용
Patching source code using user patches in /etc/portage/patches/
User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.
Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.
Patches can be dropped into any of the following directories:
- /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
- /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
- /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/
예제: Firefox에 패치 적용
www-client/firefox 꾸러미는 이빌드에서 epatch_user
를 호출하는 드문 꾸러미중 하나입니다. 따라서 다른 특별한 어떤 것도 설정을 덮어쓸 필요가 없습니다.
Firefox를 패치하려면 (예를 들어 개발자가 여러분께 Firefox를 패치와 함께 제공하려 하고 여러분이 보고한 버그가 패치되었는지 확인차 질문하는 경우) /etc/portage/patches/www-client/firefox 에 패치를 복사하고 (아마도 이후 버전과 혼동되지 않게 하려면 버전을 포함하여 완전한 이름을 사용하는 것이 가장 좋을지도 모릅니다) Firefox를 다시 빌드합니다.