Trans:EbuildHowTo
목차
Ebuild HOWTO
포티지 트리
개요
포티지 트리는 보통 /usr/portage 디렉터리 에서 찾을 수 있으며, 각각의 패키지 디렉터리가 딸려오는 카테고리 디렉터리 들이 포함되어 계층적 구조로 이루어져 있습니다. 예를 들어, /usr/portage/sys-apps/util-linux 디렉터리에서 util-linux-2.11y.ebuild 파일을 찾을 수 있습니다. 이 디렉터리에서는 또한 util-linux-2.11y.ebuild 파일과 함께 다른 버전의 util-linux에 대한 ebuild가 있을 것입니다. 이는 포티지 오버레이를 설치하지 않는 한, (버전과 상관 없이) 제각각의 패키지에 대한 모든 ebuild 가 /usr/portage에서 mycat/mypkg를 공유하기 때문입니다.
CVS에서 포티지 트리 체크아웃 하기
CVS 시스템에 익숙하지 않다면 CVS 따라하기를 보시기 바랍니다. 포티지 트리는 젠투 리눅스 트리의 gentoo-x86 모듈에서 찾을 수 있습니다. (대략 350 메가 바이트 정도 되는) 모듈을 체크아웃 하려면 먼저 안내서에 따라 CVS를 설정한 다음에 gentoo-x86 모듈을 체크아웃 합니다.
포티지 트리에 놓을 (놓지 말아야 할) 것
새 ebuild를 작성하기 전에 패키지에 대한 ebuild가 이미 작성되었지만 아직 포티지 트리에 추가가 되었는지 안되었는지를 bugs.gentoo.org에서 확인합니다. bugs.gentoo.org로 이동하여 쿼리를 선택하고 Advanced Search를 선택한 다음, pruduct에는 Gentoo Linux를, component에는 ebuilds를 선택합니다. 검색 필드에는 ebuild의 이름을 입력하고 status에서는 NEW, ASSIGNED, REOPENED 그리고 RESOLVED (RESOLVED가 중요합니다) 를 선택한 다음 쿼리를 보냅니다. 게으른 분들을 위해 링크를 준비했습니다.
일반적으로, 포티지 트리는 패치는 예제 설정 파일들과 같은 상대적으로 작은 부록 >파일들과 함께 .ebuild 파일을 저장하는 용도로만 사용하는 것이 좋습니다. 이런 파일 들은 mycat/mypkg 디렉터리가 포화되지 않도록 /usr/portage/mycat/mypkg/files 디렉>터리에 저장됩니다. 이 규칙의 예외는 젠투 미러에 위치하여 수많은 양의 대역폭과 하드디스크 용량을 낭비하지 않도록 해야 할 큰 패치 파일 ( 20KB를 넘는 패치를 위해 권장합니다 ) 에 적용됩니다. 또한 (ASCII가 아닌) 바이너리 파일을 포티지 CVS트리에 넣지 말아야 합니다. 만약 예를 들어 다른 CVS 트리에서 이렇게 할 필요가 있다면, 이유 여하를 막론하고 작은 PNG 그림 파일을 추가할 필요가 있다면 다음과 같이 -kb 옵션을 사용하여 CVS에 추가하도록 합니다.
| 코드 예제 1-1: CVS에 바이너리 파일 추가하기 |
| # cvs add -kb myphoto.png |
-kb 옵션은 CVS에게 myphoto.png가 바이너리 파일이고 특별하기 다루어져야 한다는 것을 알려줍니다. 예를 들어 이 파일에 대해 제각기 다른 두개의 버전간의 차이를 명백한 이유로 병합하도록 하지 못하게 하여야 할 것입니다. 또한 변경사항의 병합에 대해 말하자면, 포티지에 추가한 어떤 패치도 일반적으로 압축되지 않게 하는것이 좋습니다. 이렇게 하면 CVS가 변경사항을 병합하게 하고 개발자에게 충돌 내용을 정확하게 알려줍니다.
커밋할 패키지는 안정버전으로 커밋되었을때 최종 사용자를 위해 반드시 제대로 준비가 되어야 한다는 것을 잊지 마셔야 합니다. 대부분의 시스템과 여러분의 패키지를 사용할 사용자들을 만족시킬 기본 설정이 갖춰졌는지 확인 바랍니다. 만약 패키지가 깨>졌고, 어떻게 동작하게 할 수 있을지 잘 모르겠다면, 패키지 자체버전을 완성한 다른 배포본을 확인합니다. 예제를 보기위해 맨드리바 나 데비안 혹은 페도라를 확인해 볼 수 있습니다.
CVS 커밋 정책
- 커밋 하기 전에 repoman scan을 항상 실행합니다.
- 커밋 하기 전에 repoman full을 실행해 주시기 바랍니다.
- 커밋 하기 전에 emerge --pretend mypkg를 실행하여 package.mask가 완전한지 시험하고 어떤 충돌 사항이 포함되지 않도록 점검합니다.
- 커밋 하기 전에 ChangeLog를 항상 갱신합니다.
- package.mask를 커밋하는 동안 충돌이 발생하는 경우, 갱신된 패키지를 올리기 전에 갱신된 package.mask를 항상 커밋합니다.
- 항상 요소별로 커밋합니다. 새로운 라이선스로 패키지를 커밋하거나 패키지가 가려졌을 때 최신 package.mask나 혹은 라이선스를 먼저 커밋한 다음 사용자의 설치가 깨지는 것을 막기 위해 ebuild, ChangeLog, 패치들 그리고 metadata.xml을 한꺼번에 커밋합니다.
files 디렉터리
앞서 참고한 바와 같이 각각의 패키지에 포함된 하위 디렉터리로서 files/ 디렉터리가 있습니다. 여러분의 패키지에 있는 어떤 패치나 설정 파일 혹은 기타 보조 파일들이 이 디렉터리에 추가될 필요가 있을 것이며, 20KB 그 이상을 넘는 어떤 파일의 경우는 우리 사용자들이 다운 받을 (불필요한) 많은 파일들을 줄이기 위해 미러에 넣는 것이 좋습니다. mypkg-1.0-gentoo.diff나 혹은 좀 더 간단하게 1.0-gentoo.diff와 같이 패키지를 빌드하기 위해 버전과 관련된 이름으로 여러분 자신이 만든 패치에 이름을 붙이고 싶을지도 모릅니다. 또 참고하셔야 할 것은 젠투 익스텐션은 사용자들에게 이 패치가 메일링 리스트나 다른 어떤 곳에서 가져온 것이 아니라, 젠투 리눅스 개발자들이 만들었다는 것을 알려준다는 것입니다. 다시 한번 말하지만, CVS가 바이너리 파일에 대해 제대로 동작하지 않기 때문에 패치들을 압축해선 안 됩니다.
files/ 디렉터리에 넣을 모든 파일이름에 접두하거나 (mypkg-1.0 처럼)접미하는 것을 고려하여, ebuild의 제각각의 버전에서 사용하는 파일들이 다른 것들과 구별될 수 있 도록 하여 리비전들간의 변경 차이점이 보이도록 합니다. 이러한 방법이 보통 정말 좋은 방법입니다 :). 패치 이름에 좀 더 많은 의미를 부여하려 다른 접미어를 사용하고 싶으실 수도 있습니다.
files/ 디렉터리로 갈 파일이 많다면, files/1.0/ 과 같은 하위 디렉터리를 만들고 적당한 하위 디렉터리에 관련 파일들을 넣는 것을 고려해 보도록 합니다. 만약 이 방법대로 한다면, 종종 더 편한 방법으로 활용되는 파일들의 이름에 버전 정보를 넣을 필요가 없습니다.
Ebuild 스크립트
개요
Ebuild 스크립트는 전체 포티지 시스템의 기반입니다. 어떤 추가적인 설치/제거 혹은 설정의 이전 이후 과정에서 어떻게 수행할 것인지와 같은, 다운로드하고 패키지를 풀고 소스 모음을 설치하는 일련의 정보들을 지니고 있습니다. 포티지의 대부분은 파이선으로 작성되었으며, 배시를 사용하여 명령줄에서 우리가 수행하게 될 명령을 호출할 수 있도록 하기 위해 ebuild 스크립트는 배시 스크립트로 작성되었습니다. ebuild 스크립트의 이면에 있어 중요한 설계 원칙 중 하나는, 패키지를 직접 설치하려 명령줄 상에서 직졉 입력할 명령들을 보유한다는 것입니다. 이 목적을 위해 배시 문법을 사용하는 방법이 가장 좋습니다.
Ebuild 스크립트는 ebuild와 emerge 명령에 의해 번역됩니다. ebuild 명령에 대한 개념은 저수준 빌드 도구 입니다. 이를 통해 단일 ebuild를 빌드하고 설치하지만, 그 이상의 역할은 하지 않습니다. 이를 통해 또한 의존성이 만족하는지 확인하겠지만, 이들 문제를 자동으로 풀려 시도하지는 않을 것입니다. 반면에 emerge 는 고수준의 ebuild 엔진이며, 필요에 따라 의존성을 자동으로 병합하는 능력이 있고, 병합할 내용들을 추측하여 사용자들이 어떤 ebuild가 병합될 것인지 등에 대해 확인할 수 있도록 해줍니다. 일반적으로 emerge는 일부분을 제외하고 ebuild를 능가합니다. ebuild를 통해서 패키지 이머지 (반입, 패키지 해제, 컴파일, 설치, 병합) 의 다양한 부분을 통해 점진적 절차를 한번에 수행할 수 있습니다. 개발자를 위해 귀중한 디버깅 도구가 될 수 있는데, ebuild의 특정 일부분에 대한 ebuild 문제를 봉인할 수 있게 해주기 때문입니다.
ebuild 파일 이름 짓기
Ebuild 파일 이름은 다음 네 부분의 논리적 하위섹션으로 구성되어 있습니다.
pkg_ver{_suf{#}}{-r#}.ebuild
참고: 중괄호 ({})는 선택적 필드를 나타내며 문자 그대로의 패키지 이름상에서>는 나타내지 않습니다. #은 0이 아닌 양의 정수를 나타냅니다.
첫 하위 섹션, pkg는 패키지의 이름을 나타내며 소문자, 0부터 9까지의 숫자 그리고 단일 하이픈 (-), 밑줄 문자 (_) 혹은 양의 부호 (+) 문자만이 포함됩니다. 예를 들자면 util-linux, sysklogd 그리고 gtk+가 있습니다. 어떤 패키지는 이 규칙을 따르지 않지만 여러분의 패키지는 이 규칙을 따르는 것이 좋습니다.
두번째 하위 섹션, ver은 패키지의 버전을 나타내며, 보통 주 소스 타르볼의 버전과 같습니다. 버전은 1.2나 4.5.2처럼 마침표로 구분된 둘 혹은 셋 (그 이상) 의 숫자들로 구성되며, 1.4b나 2.6h처럼 마지막 숫자 다음에 단일 문자가 따라올 수도 있습니다. 패키지 버전은 패키지 이름과 하이픈 (-) 으로 연결됩니다. 예를 들면 foo-1.0, bar-2.4.6 과 같습니다.
중요: 버전 문자열에 꼬리 문자를 사용하려 한다면, 알파와 베타들은 출시 이전 버전들이고 문자 버전은 좀더 새로운 버전임을 나타내기 때문에, 패키지의 알파 혹은 베타 상태를 구분하기 위해 사용되어서는 안된다는 것을 알아두시기 바랍니다. 이는 동일한 카테고리나 이름을 지닌 다른 패키지보다 최신이거나 혹은 더 오래되었을 경우 결정할 ebuild의 버전을 포티지가 사용하기 때문에 중요한 구별 사항입니다. 패키지의 버전을 버전 번호로 충실히 표현하여 포티지가 의존성 검사 정책을 제대로 수행하도록 하는 것은 매우 중요합니다.
세번째 하위 섹션, {_suf{#}}는 다음의 미리 정의된 접미어들중 하나를 선택적으로 포함하며, 덜 최신인 것부터 가장 최신인 순으로 나열하였습니다.
| 접미어 | 의미 |
|---|---|
| _beta | 베타 릴리즈 |
| _pre | 출시 이전 |
| _rc | 출시 후보 |
| (none) | 일반 릴리즈 |
| _p | 패치 레벨(보통 정수가 딸려옴) |
이들 접미어들에는 linux-2.4.0_pre10과 같이 0이 아닌 양의 정수가 딸려옵니다. 동>일한 버전 부분을 감안하여, 접미어는 다음과 같은 순서로 나열됩니다 ( 낮다는 것은 오래됨을 의미합니다 ): _alpha < _beta < _pre < _rc < (접미어 없음)< _p.
정수가 딸려오는 동일한 접미어를 비교할 때, 큰 수가 더 최신인 것으로 간주됩니다. foo-1.0_alpha4가 foo-1.0_alpha3보다 최신인 것입니다.
패키지 이름의 네번째 하위 섹션은 젠투 리눅스에서 지정한 리비전 번호({-r#})입니다. 이 하위 섹션에서는 접미사와 마찬가지로 선택적인 요소입니다. #은 package-4.5.3-r3에서와 같이 0이 아닌 양의 정수를 의미합니다.
이 리비전 번호는 소스 타르볼의 버전과는 별개이며, 사용할 수 있는 일부 패키지의 향상된 젠투리눅스 최신 리비전임을 나타낼 때 사용됩니다. ebuild의 초기 릴리즈는 package-4.5.3과 같이 리비전 번호가 없어야 하며 Portage는 리비전 번호가 0인 것으로 간주합니다. 이는 리비전 카운팅이 1.0(초기 버전), 1.0-r1, 1.0-r2와 같이 진행됨을 의미합니다.
기존의 ebuild 파일에 사소하지 않은 향상 요소를 넣었다면, 리비전 번호를 1 증가시킨 ebuild파일을 복사하는 것이 좋습니다. 리비전 충돌이 야기될 때 항상 ChangeLog와 CVS 커밋 메세지에 변경사항을 명시해야 하는걸 잊지 마시기 바랍니다. 이렇게 하지 않으면 정책을 위반하는 것입니다.
... 그리고 실제로 ebuild 이름의 다섯번째 섹션이 있지 않나 싶습니다. 이 이름에 붙는 .ebuild 확장자가 그것입니다.
ebuild 파일의 내용
이 섹션은 ebuild를 소개합니다. ebuild에서 가능한 모든 내용을 보려면, ebuild 스>크립트에서 사용하는 자체 형식과 변수, 함수에 대해 설명하는 manpage가 있습니다: man 5 ebuild.
헤더
ebuild를 제출할 때 헤더는 /usr/portage/header.txt의 헤더와 완전히 동일해야 합니다. 무엇보다 중요한건, 무슨 일이 있더라도 수정해선 안되며, $Header: $부분에 손을 댔는지 확인해보셔야 합니다.
처음 세줄은 다음과 같이 보일 것입니다.
| 코드 예제 2-1: 유효한 헤더 |
| # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 |
