"Trans:EbuildHowTo"의 두 판 사이의 차이

Gentoo Korea Wiki
둘러보기로 가기 검색하러 가기
 
(사용자 3명의 중간 판 46개는 보이지 않습니다)
53번째 줄: 53번째 줄:
 
'''pkg_ver{_suf{#}}{-r#}.ebuild'''
 
'''pkg_ver{_suf{#}}{-r#}.ebuild'''
 
</font></div>
 
</font></div>
−
<br />
 
 
{{Note|중괄호 ({})는 선택적 필드를 나타내며 문자 그대로의 패키지 이름상에서>는 나타내지 않습니다. #은 0이 아닌 양의 정수를 나타냅니다.}}
 
{{Note|중괄호 ({})는 선택적 필드를 나타내며 문자 그대로의 패키지 이름상에서>는 나타내지 않습니다. #은 0이 아닌 양의 정수를 나타냅니다.}}
  
343번째 줄: 342번째 줄:
  
 
긴 줄에 대해서는 '\'로 마무리 합니다. 따라서
 
긴 줄에 대해서는 '\'로 마무리 합니다. 따라서
−
 
+
{{Example|코드 예제 2.3: ebuild 편집을 위해 vimrc 설정하기|<nowiki>au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh</nowiki><br />
−
{{Example|코드 예제 2.3: ebuild 편집을 위해 vimrc 설정하기|au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh<br />
+
<nowiki>au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab</nowiki>}}
−
au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab}}
 
  
 
이맥스를 사용한다면, app-emacs/gentoo-syntax(GNU Emacs용)나 app-xemacs/gentoo-syntax (XEmacs 용) 둘 중 하나를 이머지 하는 것이 좋습니다. 이 패키지들은 자동 들여쓰기와 ebuild에 대한 문법 강조 그리고 기타 젠투에 특화된 파일 유형을 위한 이맥스 메이저 모드를 제공합니다.
 
이맥스를 사용한다면, app-emacs/gentoo-syntax(GNU Emacs용)나 app-xemacs/gentoo-syntax (XEmacs 용) 둘 중 하나를 이머지 하는 것이 좋습니다. 이 패키지들은 자동 들여쓰기와 ebuild에 대한 문법 강조 그리고 기타 젠투에 특화된 파일 유형을 위한 이맥스 메이저 모드를 제공합니다.
352번째 줄: 350번째 줄:
  
 
==== USE 변수 ====
 
==== USE 변수 ====
−
USE 변수의 용도는 포티지 설정을 전체적으로 설정할 수 있게 하고 추가적 빌드 타임에 어떤 기능을 자동으로 활성화 혹은 비활성화 할 수 있게끔 합니다. 예를 들어보도록 합니다. 여러분은 그놈 팬이고 선택적으로 그놈을 지원할수 있는 옵션을 ebuild에 넣고 싶어합니다. 이 경우 /etc/make.conf의 '''USE''' 변수에 '''gnome''' 을 넣고 '''USE''' 변수에 그놈이 ''설정되지 않았는지'' 확인합니다. 젠투 리눅스는 여러분이 원하는 방식으로 정확하게 설정된 시스템을 가질 수 있도록, 압도적으로 많은 USE 옵션을 지니고 있습니다.
+
USE 변수의 용도는 포티지 설정을 전체적으로 설정할 수 있게 하고 추가적 빌드 타임에 어떤 기능을 자동으로 활성화 혹은 비활성화 할 수 있게끔 합니다. 예를 들어보도록 합니다. 여러분은 그놈 팬이고 선택적으로 그놈을 지원할수 있는 옵션을 ebuild에 넣고 싶어합니다. 이 경우 /etc/make.conf의 '''USE''' 변수에 '''gnome''' 을 넣고 '''USE''' 변수에 그놈이 ''설정되지 않았는지'' 확인합니다. 젠투 리눅스는 여러분이 원하는 방식으로 정확하게 설정된 시스템을 가질 수 있도록, 압도적으로 많은 USE 옵션을 지니고 있습니다.
  
−
{{Note|USE 변수의 설정을 해제한다면(예를 들어, <font color="blue">USE</font>로부터 <font color="blue">gnome</font>을 제거한다면), 포티지에게 그놈을 위한 선택적 빌드 타임 지원을 비활성화 하라고만 지시할 것입니다. 그러나 그놈을 필요로 하는 ebuild를 <font color="blue">emerge</font> 한다면, 해당 패키지는 기대하는 바와 같이 그놈 지원을 명백히 활성화 할 것입니다. 이는 또한 그놈이 설치되지 않았다면 자동으로 (의존성에 따라) 설치될 것임을 의미합니다. 이렇기 때문에 "실제로" <font color="blue">emerge</font>를 수행하기 전에 <font color="blue">emerge --pretend</font>를 수행하는 것은 좋은 방법입니다. 이 방법을 통해 여러분은 정확하게 어떤 패키지를 얻게 되는지 항상 알게 될 것입니다!}}
+
{{Note|USE 변수의 설정을 해제한다면(예를 들어, <b>USE</b>로부터 <b>gnome</b>을 제거한다면), 포티지에게 그놈을 위한 선택적 빌드 타임 지원을 비활성화 하라고만 지시할 것입니다. 그러나 그놈을 필요로 하는 ebuild를 <b>emerge</b> 한다면, 해당 패키지는 기대하는 바와 같이 그놈 지원을 명백히 활성화 할 것입니다. 이는 또한 그놈이 설치되지 않았다면 자동으로 (의존성에 따라) 설치될 것임을 의미합니다. 이렇기 때문에 "실제로" <b>emerge</b>를 수행하기 전에 <b>emerge --pretend</b>를 수행하는 것은 좋은 방법입니다. 이 방법을 통해 여러분은 정확하게 어떤 패키지를 얻게 되는지 항상 알게 될 것입니다!}}
  
 
여러분의 ebuild에서 '''use <variable>''' 명령을 통해 USE변수에 설정이 되었는지 검사할 수 있습니다. 보통 이 명령을 다음처럼 사용할 것입니다:
 
여러분의 ebuild에서 '''use <variable>''' 명령을 통해 USE변수에 설정이 되었는지 검사할 수 있습니다. 보통 이 명령을 다음처럼 사용할 것입니다:
  
 
{{Example|코드 예제 2.4: USE 플래그가 설정되어 있는지 찾아보기|if use X; then<br />
 
{{Example|코드 예제 2.4: USE 플래그가 설정되어 있는지 찾아보기|if use X; then<br />
−
<nowiki> # Commands specific to X...</nowiki><br/>
+
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki> # Commands specific to X...</nowiki><br/>
 
fi
 
fi
 
}}
 
}}
  
−
USE 변수는 또한 의존성을 설정하기 위해서도 사용됩니다. 예를 들어, 몇몇 USE 변수값이 설정되었을때 패키지를 요구하는 것만 원할지도 모릅니다. 이는 ebuild의 DEPEND 변수에서 '''flag? ( mycat/mypackage )''' 문법을 사용하여 해결할 수 있습니다. 이 경우 '''mycat/mypackage'''는 '''flag'''가 '''USE'''에 있을때만 필요합니다. 또한 어떤 USE 플래그가 설정되었을때와 어떤 USE 플래그가 설정되지 않았을때 어떤 의존성이 사용될지 '''flag? ( mycat/mypackage )''' 와 '''!flag? ( othercat/otherpackage )로 지정할 수도 있습니다. 이 경우 '''flag'''가 설정되어 있지 않았다면 '''othercat/otherpackage'''가 '''mycat/mypackage''' 대신 사용될 것입니다. 배시의 if를 사용하는 것이 아니라 ebuild의 이 문법을 사용했는지 확인해보시기 바랍니다. Bash 조건문은 포티지의 의존성 캐싱과 혼동되며, 배시 문법을 사용하면 ebuild를 깨지게 할 것입니다.
+
USE 변수는 또한 의존성을 설정하기 위해서도 사용됩니다. 예를 들어, 몇몇 USE 변수값이 설정되었을때 패키지를 요구하는 것만 원할지도 모릅니다. 이는 ebuild의 DEPEND 변수에서 '''flag? ( mycat/mypackage )''' 문법을 사용하여 해결할 수 있습니다. 이 경우 '''mycat/mypackage'''는 '''flag'''가 '''USE'''에 있을때만 필요합니다. 또한 어떤 USE 플래그가 설정되었을때와 어떤 USE 플래그가 설정되지 않았을때 어떤 의존성이 사용될지 '''flag? ( mycat/mypackage )''' 와 '''!flag? ( othercat/otherpackage )'''로 지정할 수도 있습니다. 이 경우 '''flag'''가 설정되어 있지 않았다면 '''othercat/otherpackage'''가 '''mycat/mypackage''' 대신 사용될 것입니다. 배시의 if를 사용하는 것이 아니라 ebuild의 이 문법을 사용했는지 확인해보시기 바랍니다. Bash 조건문은 포티지의 의존성 캐싱과 혼동되며, 배시 문법을 사용하면 ebuild를 깨지게 할 것입니다.
 +
 
 +
여기에 USE를 사용하는 중요한 요령이 있습니다. 대부분, 패키지에는 설정 과정을 수행하기 위해 '''./configure''' 스크립트를 가질 것입니다. 일반적으로 ebuild가 '''./configure'''를 사용하면, 어떤 추가적인 빌드타임 기능성은 '''./configure''' 명령으로 적당한 인>자를 전달하여 활성화되거나 비활성화될 것입니다. 여기에 이런 것들을 조작하는 가장 좋은 방법이 있습니다.<br/>
 +
 
 +
{{Example|코드 예제 2.5: USE 설정 기반 조건문|<nowiki>DEPEND="X? ( >=x11-base/xfree-4.3 )</nowiki><br/>
 +
<nowiki>mysql? ( >=dev-db/mysql-3.23.49 )</nowiki><br/>
 +
<nowiki>apache2? ( >=net-www/apache-2 )</nowiki><br/>
 +
<nowiki>!apache2? ( =net-www/apache-1* )"</nowiki><br/><br/>
 +
<nowiki>src_compile() {</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>econf \</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>$(use_enable X x11) \</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>$(use_enable mysql)</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>emake || die "Error: emake failed!"</nowiki><br/>
 +
<nowiki>}</nowiki><br/>}}
 +
 
 +
이 접근은 매우 괜찮은 결과를 가져옵니다. mysql이나 X를 위한 기본 설정(활성화/비활성화)이 어떤지에 대해 걱정할 필요가 없고, '''econf'''에게 '''USE''' 변수 값들을 기반으로 원하는 것들을 명확하게 알려줍니다. 가독성 측면에서도 조금 깔끔하다는 점은 굳이 언급하지 않겠습니다.
 +
 
 +
가끔 ebuild에는 선택적인 특징들의 충돌이 있을 것입니다. 이러한 충돌을 검사하고 오류를 반환하는 것은 가능한 해결책이 아닙니다. 대신 다른 것들중 한가지 특징에 대해 반드시 선택하여야 합니다. 이렇게 되면, 업스트림과 상의(보통 기본적으로 쓰는 것이 무엇이냐)하거나, 좀더 일반적인 기능을 제공하는 옵션을 고려하거나, 동전 뒤집기를 합니다. msmtp ebuild로부터 한가지 예를 들어보도록 하겠습니다. 패키지에는 SSL과 GnuTLS, SSL과 OpenSSL 혹은 SSL을 모두 사용하지 않는 방식을 사용할 수 있습니다. 왜냐면 GnuTLS는 OpenSSL에 비해 더 많은 기능을 지니고 있는데, 이게 장점입니다:
 +
 
 +
{{Example|코드 예제 2.6: 충돌 기능 다루기|<nowiki>src_compile() {</nowiki>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>local myconf</nowiki><br/><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>if use gnutls ; then</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>myconf="${myconf} --enable-ssl --with-ssl=gnutls"</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>elif use ssl ; then</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>myconf="${myconf} --enable-ssl --with-ssl=openssl"</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>else</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>myconf="${myconf} --disable-ssl"</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>fi</nowiki><br/><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>econf \</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<nowiki># Other stuff</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>${myconf}</nowiki><br/><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>emake || die "make failed"</nowiki><br/><nowiki>}</nowiki><br/>}}
 +
 
 +
USE 변수에 대한 최신 테이블을 계속 보시려면, [http://www.gentoo.org/dyn/use-index.xml 이 곳]으로 가시기 바랍니다.
 +
 
 +
=== 파일 시스템 위치 ===
 +
==== FHS에 대한 소개 ====
 +
젠투 리눅스에서 사용하는 파일 시스템 배치 표준은 File system Hierarchy Standard의 약자인 FHS를 거의 따릅니다. 표준에 대한 간단한 설명은 여기에 있습니다. 완전한 명세서를 보시려면 [http://www.pathname.com/fhs/ http://www.pathname.com/fhs/]로 가시기 바랍니다.
 +
 
 +
{{Note|/opt 계층은 FHS의 섹션 3.12 에 있습니다. 섹션 4.4 에서는 /usr/X11R6 디렉터리에 대해 다룹니다. KDE와 GNOME은 특별히 다루어지지 않았고 현재 버전의 FHS에서 언급되지도 않았습니다.}}
 +
 
 +
==== 시스템에 패키지를 적용하는 방법 ====
 +
보통 패키지가 autoconf와 automake를 사용한다면 기본 설치 대상경로는 대부분 몇몇 예외를 제외하고 올바릅니다:
 +
 
 +
* 프로그램을 /bin, /sbin, /usr/bin, 혹은 /usr/sbin에 설치한다면 프로그램의 관련 맨 페이지는 /usr/share/man 트리에 설치될 것입니다. 이는 종종 ebuild에서 '''./configure --mandir=/usr/share/man'''을 지정하여 수행할 수 있습니다.
 +
 
 +
* GNU info 파일은 X11, 그놈, KDE와 관련된 프로그램이나 도구에 대한 것일지라도 항상 /usr/share/info 에 설치될 것입니다. 여기서 참고할 것은 /usr/share/info 는 오직 GNU info 파일이 위치하게 될 공식 경로입니다. 대부분의 '''./configure''' 스크립트가 '''/usr/info'''에 GNU info 파일을 설치하는 것을 기본으로 하는데, 종종 '''./configure'''에 '''--infodir=/usr/share/info''' 인자를 붙여 호출할 필요가 있습니다.
 +
 
 +
* 문서 파일들은 /usr/share/doc에 설치되며, 제각각의 프로그램에 대하여 하위 디렉터리에 프로그램의 이름과 버전, 리비전을 반영합니다. 이는 그놈, KDE, X11 그리고 콘솔을 기반으로 하는 모든 프로그램에 적용됩니다. 그러나 어떤 프로그램은 추가적인 문서를 설치할 것이고 그들 자신의 고유목적에 따라 /usr/share 계층으로 지원 파일을 넣을 것입니다.
 +
 
 +
* X11과 관련된 프로그램과 라이브러리는 항상 /usr에 설치되겠지만 /usr/X11R6로 바로 들어가는 것은 아닐 것입니다. /usr/X11R6 계층을 X 윈도 시스템 버전 11 릴리즈 번호 6을 위해 예약하였습니다. 이는 아마도 몇몇 다른 배포판이 그렇게 했다기보단 FHS의 문자적인 해석에 비중을 두기 때문인지도 모릅니다.
 +
 
 +
* 그놈과 KDE 프로그램과 같은 것들은 항상 /usr 로 설치될 것입니다.
 +
 
 +
{{Important|몇몇 배포판은 그놈과 KDE를 /opt로 설치하는 것을 선택합니다. 실제로 그들 파일을 어디에 설치할 것인가에 대한 내용이 이들 데스크탑 환경에 대해 표준으로 존재하지 않습니다. 단순성과 일관성 고려측면에서, 젠투는 모든 KDE와 그놈 패키지를 선택하기 위해 /usr 디렉터리를 선택했습니다.}}
 +
 
 +
일반적으로, /usr 트리에 이들 파일을 설치하는 ebuild를 가지고 있을 것입니다. 몇몇 프로그램은 혼동을 야기하는 그놈이나 KDE, X11 라이브러리를 포함하거나 제외하여 컴파일하고 링크할 수 있습니다. 해결책이 있다면 모호성을 방지하기 위해 모두 /usr에 설치하고 ebuild 저작자를 위해 복잡성을 줄이는 것입니다. 프로그램의 파일이 설치될 위치는 특정 '''USE''' 변수의 존재와 누락에 관련되어서는 ''안될 것''입니다. 따라서, 포티지 트리의 ebuild는 ''거의 항상'' 배타적으로 /usr 계층에 설치합니다.
 +
<br/>
 +
{{Note|젠투 리눅스에서 /opt 디렉터리는 바이너리만 존재하는 패키지를 위해 예약되었습니다. 그 예로 mozilla-bin, acroread, netscape 그리고 realplayer가 포함됩니다. 여기에 설치될 패키지는 보통 /etc/env.d/foo와 같은 파일을 필요로 할 것입니다. 이를 통해 경로와 추가 변수를 환경에 포함할 수 있습니다. /etc/env.d에 대해 더 알아보시려면 [[http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5 이 문서]] 를 방문해보시기 바랍니다.}}
 +
 
 +
=== 포티지 스크립트와 유틸리티 ===
 +
==== 공용 스크립트 ====
 +
이 스크립트는 시스템 관리자가 패키지를 설치하고 제거하며 패키지 데이터베이스를 유지하는데 사용합니다.
 +
 
 +
'''ebuild'''는 포티지 시스템의 주 엔진입니다. 이는 패키지 풀기, 컴파일, 설치, 병합 그리고 병합해제와 같은 모든 주된 작업을 수행합니다. 이는 다음 명령으로 호출됩니다: '''ebuild path/to/package.ebuild command'''. 사용할 수 있는 명령은 다음과 같습니다:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col" | 명령
 +
! scope="col" | 설명
 +
! scope="col" | 관련 '''ebuild''' 함수
 +
|-
 +
| <font color="blue">setup</font><font color="red"><sup>*</sup></font>
 +
| ebuild가 수행되기 전에 필요한 어떤 잡다한 명령들을 수행합니다
 +
| pkg_setup
 +
|-
 +
| <font color="blue">depend</font>
 +
| |패키지를 빌드하는데 필요한 의존성을 표시합니다
 +
| N/A
 +
|-
 +
| <font color="blue">merge</font><font color="red"><sup>*</sup></font>
 +
| 시스템에 패키지를 풀고, 컴파일, 설치 그리고 병합합니다
 +
| N/A
 +
|-
 +
| <font color="blue">qmerge</font><font color="red"><sup>*</sup></font>
 +
| 이미 시스템에 패키지가 풀리고, 컴파일 설치 과정이 실행되었다 가정한 상태에서 파일 시스템에 패키지를 병합합니다
 +
| N/A
 +
|-
 +
| <font color="blue">unpack</font><font color="red"><sup>*</sup></font>
 +
| 작업 디렉터리로 소스 타르볼을 풉니다
 +
| src_unpack
 +
|-
 +
| <font color="blue">compile</font><font color="red"><sup>*</sup></font>
 +
| 패키지를 컴파일 합니다
 +
| src_compile
 +
|-
 +
| <font color="blue">rpm</font>
 +
| 패키지로부터 RPM을 만듭니다
 +
| N/A
 +
|-
 +
| <font color="blue">package</font>
 +
| 젠투의 '''tbz2''' 패키지를 만듭니다
 +
| N/A
 +
|-
 +
| <font color="blue">prerm</font><font color="red"><sup>*</sup></font>
 +
| 패키지를 제거하기 이전 단계를 실행합니다
 +
| pkg_prerm
 +
|-
 +
| <font color="blue">postrm</font><font color="red"><sup>*</sup></font>
 +
| 패키지를 제거하고 난 단계를 실행합니다
 +
| pkg_postrm
 +
|-
 +
| <font color="blue">preinst</font><font color="red"><sup>*</sup></font>
 +
| 패키지를 설치하기 이전 단계를 실행합니다
 +
| pkg_preinst
 +
|-
 +
| <font color="blue">postinst</font><font color="red"><sup>*</sup></font>
 +
| 패키지를 설치하고 난 단계를 실행합니다
 +
| pkg_postinst
 +
|-
 +
| <font color="blue">config</font>
 +
| 패키지가 병합되면 기본 설정내용으로 설정합니다
 +
| pkg_config
 +
|-
 +
| <font color="blue">touch</font><font color="red"><sup>*</sup></font>
 +
| 패키지의 각각의 소스 아카이브에 대한 mtimes를 새로 고칩니다
 +
| N/A
 +
|-
 +
| <font color="blue">clean</font><font color="red"><sup>*</sup></font>
 +
| 패키지의 작업 디렉토리를 비웁니다
 +
| N/A
 +
|-
 +
| <font color="blue">fetch</font><font color="red"><sup>*</sup></font>
 +
| 패키지 소스 타르볼을 가져옵니다
 +
| N/A
 +
|-
 +
| <font color="blue">manifest</font><font color="red"><sup>*</sup></font>
 +
| 패키지에 대한 매니페스트를 만듭니다
 +
| N/A
 +
|-
 +
| <font color="blue">test</font><font color="red"><sup>*</sup></font>
 +
| 패키지에 대한 자체 테스트 루틴을 실행합니다
 +
| src_test
 +
|-
 +
| <font color="blue">install</font><font color="red"><sup>*</sup></font>
 +
| 이미지 디렉터리에 패키지를 설치합니다
 +
| src_install
 +
|-
 +
| <font color="blue">unmerge</font>
 +
| 파일 시스템으로부터 패키지를 병합해제합니다
 +
| N/A
 +
|}
 +
 
 +
{{Note|별표 문자(*)와 함께 있는 명령은 개발자들만 사용합니다.}}
 +
 
 +
'''emerge'''는 재귀적으로 패키지와 파일 시스템의 모든 의존요소를 병합합니다. 이 명령은 많은 옵션들이 있습니다. 목록을 보려면 '''emerge --help'''를 입력합니다.
 +
 
 +
'''env-update'''는 설치된 패키지가 변경한 내용이 들어있는 설정 파일들을 새로 고칩니다 (/etc/ld.so.conf와 /etc/profile.env도 포함하지만 제한적임)
 +
 
 +
==== 비공개 스크립트와 명령들 ====
 +
일반적인 작업을 수행할 ebuild 파일에서 사용할 수 있는 스크립트 입니다.
 +
 
 +
기초적인 분들을 위해 /usr/lib/portage/bin에 있는 스크립트에 대해 보도록 하겠습니다.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col" | 명령
 +
! scope="col" | 기본값
 +
! scope="col" | 설명
 +
! scope="col" | 예제
 +
|-
 +
| diropts
 +
| -m0755
 +
| '''dodir'''을 실행할때 사용하는 옵션을 설정합니다
 +
| diropts -m0750
 +
|-
 +
| dobin
 +
| N/A
 +
| 지정된 바이너리를 DESTTREE/bin에 설치합니다
 +
| dobin wmacpi
 +
|-
 +
| docinto
 +
| ""
 +
| '''dodoc'''이 사용하는 관련 하위 디렉터리 (DOCDESTTREE)를 설정합니다
 +
| docinto examples
 +
|-
 +
| dodir
 +
| N/A
 +
| ${D}를 명백하게 다루는 디렉토리를 만듭니다
 +
| dodir /usr/lib/newpackage
 +
|-
 +
| dodoc
 +
| N/A
 +
| 지정된 파일을 패키지의 문서 디렉토리 (/usr/share/doc/${PF}/DOCDESTTREE)로 설치합니다('''docinto''' 참조)
 +
| dodoc README *.txt
 +
|-
 +
| doexe
 +
| N/A
 +
| EXEOPTIONS ('''exeopts''' 참조) 모드로 지정된 파일을 EXEINTO ('''exeinto''' 참조)가 정의한 PATH로 설치합니다.
 +
| doexe ${FILESDIR}/quake3
 +
|-
 +
| dohard
 +
| N/A
 +
| ${D}를 명백하게 다루는 하드링크를 만듭니다
 +
| dohard ls /bin/dir
 +
|-
 +
| dohtml
 +
| N/A
 +
| 지정한 파일과 디렉터리를 /usr/share/doc/${PF}/html에 설치합니다
 +
| dohtml -r doc/html/*
 +
|-
 +
| doinfo
 +
| N/A
 +
| 지정한 파일을 /usr/share/info에 설치하고, gzip으로 압축합니다
 +
| doinfo doc/*.info
 +
|-
 +
| doins
 +
| N/A
 +
| '''INSOPTIONS''' ('''insopts''' 참조) 모드로 지정된 파일을 INSDESTTREE('''insinto''' 참조)에 설치합니다
 +
| doins *.png icon.xpm
 +
|-
 +
|  dolib
 +
|  N/A
 +
| 지정된 라이브러리를 0644모드로 DESTTREE/lib에 설치합니다
 +
| dolib *.a *.so
 +
|-
 +
| dolib.a
 +
|  N/A
 +
| 지정된 라이브러리를 0644모드로 DESTTREE/lib에 설치합니다
 +
| dolib.a *.a
 +
|-
 +
| dolib.so
 +
| N/A
 +
| 지정된 라이브러리를 755모드로 DESTTREE/lib에 설치합니다
 +
| dolib.so *.so
 +
|-
 +
| doman
 +
| N/A
 +
| 지정된 파일을 파일의 접미문자에 따라 /usr/share/man/manX에 설치합니다 (file.1 은 man1에 복사됨)
 +
| doman *.1 *.5
 +
|-
 +
| dosbin
 +
| N/A
 +
| 파일을 DESTTREE/sbin에 설치하고, 실행가능한지 확인합니다
 +
| dosbin ksymoops
 +
|-
 +
| dosym
 +
| N/A
 +
| ${D}를 명백하게 다루는 심볼릭 링크를 만듭니다
 +
| dosym gzip /bin/zcat
 +
|-
 +
| emake
 +
| N/A
 +
| '''MAKEOPTS'''로 make를 실행합니다. 어떤 패키지는 병렬로 만들어질 수 없어서 대신 '''emake -j1'''을 사용합니다. 패키지를 만들기 위해 전달할 추가 인자가 필요하다면, emake 명령에 붙여주기만 하면 됩니다. 사용자들은 emake에 추가 플래그를 넘겨주기 위해 '''EXTRA_EMAKE''' 환경 변수를 설정할 수 있습니다.
 +
| emake
 +
|-
 +
| exeinto
 +
| /
 +
| '''doexe'''명령을 위해 루트 (''EXEDESTTREE'')를 설정합니다
 +
| exeinto /usr/lib/${PN}
 +
|-
 +
| exeopts
 +
| -m0755
 +
| '''doexe'''를 실행할 때 사용하는 옵션을 설정합니다
 +
| exeopts -m1770
 +
|-
 +
| fowners
 +
| N/A
 +
| ${D}를 명백하게 다루는 chown 명령을 통해 지정된 소유규칙을 지정된 파일에 적용합니다.
 +
| fowners root:root /sbin/functions.sh
 +
|-
 +
| fperms
 +
| N/A
 +
| ${D}를 명백하게 다루는 chown 명령을 통해 지정된 권한을 지정된 파일에 적용합니다.
 +
| fperms 700 /var/consoles
 +
|-
 +
| insinto
 +
| /usr
 +
| '''doins'''명령을 위해 루트 (''INSDESTTREE'')를 설정합니다
 +
| insinto /usr/include
 +
|-
 +
| insopts
 +
| -m0644
 +
| '''doins'''를 실행할 때 사용하는 옵션을 설정합니다
 +
| insopts -m0444
 +
|-
 +
| into 
 +
| /usr
 +
| 모든 'do' 명령들 ('''dobin''', '''dolib''', '''dolib.a''', '''dolib.so''', '''domo''', '''dosbin''')을 위해 타겟 접두 경로(DESTTREE)를 설정합니다.
 +
| into /
 +
|-
 +
| libopts
 +
| -m0644
 +
| '''dolib'''를 실행할때 사용하는 옵션을 설정합니다
 +
| libopts -m0555
 +
|-
 +
| newbin
 +
| N/A
 +
| 지정된 바이너리를 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''dobin'''의 래퍼입니다
 +
| newbin ${FILESDIR}/vmware.sh vmware
 +
|-
 +
| newdoc
 +
| N/A
 +
| 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''dodoc'''의 래퍼입니다
 +
| newdoc README README.opengl
 +
|-
 +
| newexe
 +
| N/A ||지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''doexe'''의 래퍼입니다
 +
| newexe ${FILESDIR}/xinetd.rc xinetd
 +
|-
 +
| newins
 +
| N/A ||지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''doins'''의 래퍼입니다
 +
| newins ntp.conf.example ntp.conf
 +
|-
 +
| newman
 +
| N/A
 +
| 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''doman'''의 래퍼입니다
 +
| newman xboing.man xboing.6
 +
|-
 +
| newsbin
 +
| N/A
 +
| 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 '''dosbin'''의 래퍼입니다
 +
| newsbin strings strings-static
 +
|-
 +
| prepall
 +
| N/A
 +
| '''prepallman''', '''prepallinfo''' 그리고 '''prepallstrip'''를 실행합니다. 또한 /opt/*/lib, /lib, /usr/lib 그리고 /usr/X11R6/lib 에 있는 모든 라이브러리가 실행가능한지 확인합니다. 또한 일부 흩어진 aclocal 매크로를 /usr/share/aclocal에 옮겨줍니다
 +
| prepall
 +
|-
 +
| prepalldocs
 +
| N/A
 +
| 이것이 수행하는 동작이 포티지 버전이 바뀌면서 변경되어 새로운 ebuild에서는 이 함수를 사용하지 않는 것이 좋습니다.
 +
| prepalldocs
 +
|-
 +
| prepallinfo
 +
| N/A
 +
| /usr/share/info의 모든 info 파일을 재귀적으로 gzip으로 압축합니다
 +
| prepallinfo
 +
|-
 +
| prepallman
 +
| N/A
 +
| /opt/*/man/*, /usr/share/man/*, /usr/local/man/*, /usr/X11R6/share/man/* 에 있는 모든 맨 페이지를 gzip으로 압축하고 일부 심볼릭 링크 경로를 확실하게 수정합니다.
 +
| prepallman
 +
|}
 +
 
 +
=== 패키지 의존성 ===
 +
==== 의존성이 중요한 이유 ====
 +
포티지는 소스로부터 어떤 하나의 프로젝트 (프로그램이나 라이브러리) 를 빌드하는 통합적인 수단을 제공해주는 편의 스크립트의 그 이상입니다. 또한 ebuild에 지정하여 처리할 필요한 어떤 의존요소를 가져오고 설치할 것입니다.
 +
 
 +
공식 ebuild에서는 모든 의존요소가 이미 지정되어 있어 '''emerge net-www/mozilla/mozilla-1.0'''을 실행하면, 포티지는 모질라를 빌드하고 실행하는데 필요한 모든 라이브러리가 모질라를 빌드하기 전에 적당하게 설치하는 것을 확실하게 할 것입니다.
 +
 
 +
포티지는 또한 빌드타임 의존 요소와 실행시간 의존 요소를 구분합니다. (경고: 현재로서는, 포티지는 모든 빌드타임, 실행시간 의존요소와 나머지의 것들을 설치합니다. 다음 단계에서, 설치 내용을 손 볼 가능성이 있어, 실행 시간 의존 요소만 설치된 채로 남아있게 됩니다)
 +
==== ebuild 파일(DEPENDS 요소)에 의존성을 지정하는 방법 ====
 +
foo-x.y.z.ebuild에 있는 '''DEPEND''' 변수는 포티지에게 어떤 패키지를 빌드할 필요가 있는지를 알려줍니다. '''RDEPEND''' 변수는 foo를 실행하는데 필요한 패키지를 지정합니다. '''RDEPEND''' 는 DEPEND와 같다 해도 명시적으로 설정되어야 하는데 DEPEND에 기본으로 지정되>어 있는 것이 나중에 포티지로부터 제거되도록 계획되어 있기 때문입니다.
 +
 
 +
{{Example|코드 예제 5.1: Depend 예제|<nowiki>DEPEND="virtual/opengl</nowiki><br/>
 +
&nbsp;&nbsp;&nbsp;&nbsp;<nowiki>dev-libs/libxml2"</nowiki><br/>
 +
<nowiki>RDEPEND="${DEPEND}"</nowiki>
 +
}}
 +
 
 +
이는 foo-x.y.z를 빌드하도록 포티지에게 일러줍니다. virtual/opengl 과 dev-libs/libxml2 패키지가 필요합니다. 여기에는 opengl이나 libxml2의 어떤 버전이 필요한지 알려주진 않으며 이는 "실행할 어떤 것"을 의미합니다.
 +
 
 +
이 "실행할 것"이 물론 조금 무섭(?)기도 하고, 일반적으론 동작하지 않을 것입니다. 그러나 라이브러리라면, 항상 100% 바이너리 호환을 지니게 하는 노력이 매우 어렵지만, 실제적으론 동작합니다. 다른 라이브러리에 대해, 물론 버전 의존 요소를 지정할 수 있습니다.
 +
 
 +
{{Example|코드 예제 5.2: 버전 예제|<nowiki>>=sys-apps/bar-1.2</nowiki><br/>
 +
<nowiki>=sys-apps/baz-1.0</nowiki>}}
 +
 
 +
<nowiki>>=</nowiki> 와 =는 무얼 원하는지에 대한 판단을 수행합니다. sys-apps/bar는 버전 1.2 이상이면 됩니다 (이 얘기는 sys-apps/bar-2.0이면 된다는 얘깁니다). 그리고 sys-apps/baz의 버전은 1.0만 허용됩니다. 버전 개요에 대해 더 많이 알고 싶다면 [http://darkcircle.myhome.tv/wiki/wiki.php?GentooEbuildHowto&amp;action=show&amp;dummy=1#s-1.2.2 ebuild 파일 이름 짓기]에 있는 섹션을 보시기 바랍니다.
 +
 
 +
버전 의존 요소를 지정하는 다른 방법은 다음과 같습니다:
 +
 
 +
{{Example|코드 예제 5.3: 버전 의존요소 지정하기|<nowiki>~sys-apps/qux-1.0</nowiki><br/>
 +
<nowiki>=sys-apps/foo-1.2*</nowiki><br/>
 +
<nowiki>!sys-libs/gdbm</nowiki>}}
 +
 
 +
~sys-apps/qux-1.0 는 qux-1.0의 최신 포티지 리비전을 선택할 것입니다.
 +
 
 +
=sys-apps/foo-1.2* 는 1.2시리즈의 최신 멤버를 선택하지만 1.3이상은 무시할 것입니다. 이 얘기는 foo-1.2.3 와 foo-1.2.0는 유효하지만, foo-1.3.3, foo-1.3.0 그리고 foo-1.1.0는 그렇지 않다는 것입니다. 이때 문제가 될 수 있는 foo-1.22.3 또한 일치할 것이라는 것 알아두
 +
시기 바랍니다.
 +
 
 +
!sys-libs/gdbm 는 이미 gdbm이 이머지 되었을 때 이 패키지가 이머지 되는 것을 막을 것입니다.
 +
 
 +
==== 중요한 참고 ====
 +
DEPEND와 RDEPEND변수에 잘못 지정하는 많은 경우들이 있습니다. 의존요소를 작성할 때 따라야 할 중요한 점들이 있습니다.
 +
 
 +
* ''CATEGORY는 항상 포함합니다.''
 +
예를 들어 '''>=x11-libs/gtk+-2'''지, '''>=gtk+-2'''가 아닙니다.
 +
* ''>= 의존 요소에는 별표 문자(*)를 넣지 않습니다.''
 +
예를 들어 '''>=x11-libs/gtk+-2*'''보다는 '''>=x11-libs/gtk+-2'''가 되어야 합니다.
 +
* ''메타패키지를 의존 요소로 절대 걸지 않습니다.''
 +
다시 말해 항상 libgnome과 같은 특정 라이브러리에 의존하는 gnome-base/gnome을 의존 요소로 걸면 안됩니다.
 +
* ''한 줄에 하나의 의존 요소''
 +
한 줄에 여러 의존요소를 적지 않습니다. 읽기 괴랄해지고 파악하기 어렵습니다.
 +
* GTK: GTK+1 프로그램을 위해 항상 ''=x11-libs/gtk+-1.2*''를 사용합니다.
 +
 
 +
덧붙여 여러분의 패키지에 모든 의존 요소가 완전히 작성되었는지 확인하는데 중요한 사항들입니다.
 +
 
 +
* ''설치된 바이너리/라이브러리를 살펴봅니다''
 +
DT_NEEDED 항목을 나열해보기 위해 scanelf -n 과 같은 도구를 사용합니다.
 +
* ''configure.in이나 configure.ac를 살펴봅니다''
 +
패키지를 검사하기 위해 이곳을 봅니다. pkg-config checks나 특정 버전을 확인하는 AM_* 함수를 사용하면 찾을 내용을 살펴볼 수 있습니다.
 +
* ''포함된 .spec 파일을 살펴봅니다''
 +
의존요소를 바로 볼 수 있는 방법은 관련된 의존 요소가 포함된 .spec파일을 찾아보는 것입니다. 그러나 의존 요소들의 결정적으로 완벽한 목록이 될 거라고 믿지는 마시기 바랍니다.
 +
* ''패키지의 README와 INSTALL를 읽습니다''
 +
패키지를 빌드하고 설치하기 위한 유용한 정보가 들어있기도 합니다.
 +
* ''pkg-config, 문서 생성 프로그램 등의 비 바이너리 의존성을 상기합니다''
 +
보통 빌드 과정에서는 intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc 등과 같은 의존 요소를 필요로 합니다. 명확하게 명시되었는지 확인해보도록 합니다.
 +
 
 +
DEPEND 요소에 대한 최신 세부내용을 보시려면 ebuild의 맨 페이지 섹션 5를 참고바랍니다: '''man 5 ebuild'''.
 +
 
 +
=== 테스트 및 배포 ===
 +
==== ChangeLog ====
 +
ebuild를 새로 받을(혹은 새로 작성할) 때마다 이에 대한 ChangeLog를 새로 고쳐(혹은 새로 만들어)야 합니다. skel.ChangeLog에는 기반으로 사용할 수 있는 간단한 ChangeLog가 있습니다.
 +
 
 +
ChangeLog의 목적은 무엇을 했는지, 왜 했는지, 누가 했는지를 문서화 하는 것입니다. 이를 통해 개발자와 사용자가 변경사항을 쉽게 추적할 수 있습니다.
 +
 
 +
ChangeLog는 기본적으로 사용자에게 초점이 맞춰져 있기 때문에, 이 시점에서 반드시 짧게 작성하는 것을 유지해야 하며, 내부의 기술적 세부내용에 대해 장황하게 늘어놓는 것을 삼가해야 합니다.
 +
 
 +
==== 여러분의 ebuild를 따로 저장하기 ====
 +
ebuild를 테스트 할 수 있게 하고, 포티지가 이것을 알아채게끔 하려면, 기존의 알려진 디렉터리에 이것(ebuild)들을 넣어야 합니다. 포티지는 /etc/make.conf에 설정할 수 있는 PORTDIR_OVERLAY변수를 사용할 것입니다. 사용할 디렉토리를 이 변수에 (/usr/local/portage 처럼) 설정할 필요가 있습니다.
 +
 
 +
이 디렉토리에 /usr/portage와 같은 구조 (와 카테고리) 를 사용하여야 합니다.
 +
 
 +
PORTDIR_OVERLAY를 사용할 때, ebuild는 시스템에 남아있게 되고, '''emerge sync'''를 수행해도, 포티지가 이들이 남아있음을 인지합니다.
 +
 
 +
==== 패키지 시험 ====
 +
이 패키지가 동작하는지 어떻게 테스트 할 것인지를 생각해보도록 합니다. 가끔 개발자는 패키지의 기본적인 기능성을 테스트 하기 위해 이미 들어간 '''make test'''나 '''make check'''루틴을 보유합니다. 만약 이렇다면 '''FEATURES=test ebuild foo-x.y.z.ebuild test'''를 실행할 때 '''make test'''나 '''make check'''루틴을 실행할 것입니다. 이게 깨졌다면 이게 제대로 동작하도록 고쳐보려 할 것입니다 (그리고 업스트림 개발자에게 패치를 제공할 것입니다).
 +
 
 +
이 상황이 고려되지 않았다면 '''src_test''' 루틴을 ebuild에 넣는 것을 고려해보도록 합니다. '''src_install'''루틴을 수행하기 전에 이것을 먼저 실행할 것이고 여러 아키텍처에서 프로그램이 동작하는 것을 시험하는데 매우 도움이 될 수 있을 것입니다. 여기에 루틴을 추가
 +
하여 패키지의 기능에 대한 지식을 필요로 하지 않는다면 아키텍처 개발자는 퍽이나 좋아라 할 것입니다.
 +
 
 +
ebuild의 일반적인 요구사항을 염두에 두기 바랍니다. '''src_test'''루틴은 반드시 대화형이어선 안됩니다. 만약 시험 루틴이 다른 패키지에 의존한다면 '''test''' USE플래그를 사용하여 선택적 컴파일 시간의 '''DEPEND'''ancy를 지정할 수 있도록 합니다. 또한, '''src_test''' 루틴은 사용자들이 포티지의 실행으로 종종 성공적으로 실행하지 못하는 그래픽 X 프로그램을 위해서라면 그다지 추천하지 않는다는 것을 알아두셨으면 합니다.
 +
 
 +
==== 유용한 시험 도구 ====
 +
ebuild를 작성하고 관리하기 위해 도움을 줄 몇몇 유용한 도구들이 있습니다.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col" | 도구
 +
! scope="col" | 패키지
 +
! scope="col" | 설명
 +
|-
 +
| repoman
 +
| sys-apps/portage
 +
| 절차상 CVS 체크를 도와주는 개발자 전용 도구 입니다. 일반적인 수많은 QA를 수행하고, 포티지 트리를 깨뜨리지 않을 CVS에 추가된 파일을 확인합니다
 +
|-
 +
| ccache
 +
| dev-util/ccache
 +
| 미리 처리된 파일을 유지하는 도구이며, 재 컴파일을 매우 빠르게 처리합니다. '''ccache'''를 /etc/make.conf의 FEATURES 변수에 넣어주셔야 합니다
 +
|-
 +
| sandbox
 +
| sys-apps/sandbox
 +
| 샌드박스 환경을 만드는 쉘을 실행합니다. 포티지로 패키지 내용을 빌드하고 직접 디버깅하는 동일한 환경으로 진입하는데 유용합니다.
 +
|-
 +
| echangelog
 +
| app-portage/gentoolkit-dev
 +
| 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.
 +
|}
 +
 
 +
 
 +
[[Category:GentooTrans]]

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


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
# $Header: $


변수

모든 ebuild파일의 첫 부분은 변수들로 채워집니다. 제각각의 변수에 대한 내용을 보려면 개발설명서를 보도록 합니다.

함수

패키지의 빌드와 설치과정을 제어할 수 있는 ebuild 파일에서 정의할 수 있는 많은 제각각의 함수들이 있습니다.

함수 용도
pkg_setup 어떤 기타 조건 작업을 수행할때 이 함수를 사용합니다. 이는 아마도 기존의 설정파일을 검사하는 기능이 있을 것입니다.
pkg_nofetch (라이센스 문제와 같은) 어떤 문제로 인해 소스가 포티지에 의해 자동으로 다운로드 되지 않을때 필요한 동작을 사용자에게 안내합니다. RESTRICT="fetch"와 함께 사용합니다. 이 함수에서는 메세지만 보여주기만 하며, die를 호출하지 않습니다.
src_unpack 소스 패키지를 풀고 패치를 적용하며 autotools와 같은 외부 프로그램을 실행할때 이 함수를 사용합니다. 기본적으로 이 함수는 A에 나열된 패키지를 풉니다. 기본 작업 디렉터리는 WORKDIR에 정의되어 있습니다.
src_compile 패키지를 설정하고 빌드할때 이 합수를 사용합니다. 기본 작업 디렉터리는 S' 입니다.
src_install D에 있는 이미지로 패키지를 설치할 때 이 함수를 사용합니다. 패키지가 automake를 사용한다면 emake DESTDIR="${D}" install로 간단하게 수행할 수 있습니다. D 를 사용하여 패키지의 파일을 설치할 때 루트계정으로 수행하는지 확인하도록 합니다. 기본 작업 디렉터리는 S입니다.
src_test FEATURES="test"가 설정되었고, RESTRICT="test"가 해제되었을 경우에만 실행되며, 이 함수는 기본적으로 제공되는 의존성에 따라 "make test"나 "make check"를 실행하여 ${S} 디렉터리에 있는 어떤 Makefile들로부터 존재하는 시험 기능들을 실행합니다. 사용자 정의 시험 설정을 만드는 것에 우선될 수 있습니다.
pkg_preinst 이 함수의 명령은 시스템에 패키지 이미지를 병합하기 전에 실행할 것들입니다.
pkg_postinst 이 함수의 명령은 시스템에 패키지 이미지를 병합하고 나서 실행할 것들입니다.
pkg_prerm 이 함수의 명령은 시스템으로부터 패키지를 병합해제하기 전에 실행할 것들입니다.
pkg_postrm 이 함수의 병령은 시스템으로부터 패키지를 병합해제하고 난 후에 실행할 것들입니다.
pkg_config 패키지가 설치되고 나서 초기 설정을 수행할때 이 함수를 사용합니다. 이 함수의 모든 경로는 / 가 아닌 사용자 지정 설치 루트를 가리키는 ROOT가 접두사로 붙게 됩니다. 이 함수는 오직 사용자가 실행하려 할때만 사용합니다: emerge --config =${PF}
도우미 함수

또한 ebuild에서 다음의 도우미 함수를 사용할 수도 있습니다.

함수 용도
use 하나 이상의 USE 플래그가 정의되었는지 확인합니다. 만약 정의되어 있다면 shell에 true를 반환합니다. 아무것도 없어도 표준 출력에 표시해줍니다. 자세히 보여주려면, USE 플래그가 정의되었을 때 USE플래그를 보여주는 usev를 사용해보기 바랍니다.
has_version 제각각의 패키지에 대해 요청된 버전이 시스템에 있다면 1을 반환합니다. has_version >=sys-libs/glibc-2.3.0과 같이 사용합니다.
best_version 요청한 category/package의 category/package-version을 반환합니다. best_version x11-libs/gtk+extra와 같이 사용합니다.
use_with 이 함수는 USE플래그가 정의되었는지 확인하고 "- -with-foobar" 나 "- -without-foobar"를 즉시 반환합니다. 만약 단 한 가지의 인자를 사용한다면, 그 인자는 USE플래그와 with(out) 문자열에 해당됩니다. 그렇지 않다면 첫번째 인자는 USE플래그이고 두번째 인자는 with(out) 문자열입니다. use_with truetype freetype와 같이 사용하면 USE 플래그중 truetype을 사용한다면 "- -with-freetype"을 표시할 것입니다.
use_enable use_with와 동일하지만, "- -enable-foobar" 혹은 "- -disable-foobar"를 즉시 반환합니다.
check_KV 포티지가 파악하는 커널 버전을 확인합니다. 만약 안되면 오류를 출력하고 죽습니다. 스크립트 상에 커널 버전이 필요하다면, 포티지가 자동으로 정의한 KV 변수를 사용해보기 바랍니다. gentoo-sources-2.4.20-r6를 실행하는 시스템에서 KV는 2.4.20값을 지니고 있을 것입니다.
keepdir (필요한 경우) 주어진 디렉터리에 .keep 파일을 만들어서 자동으로 제거되지 않도록 합니다. 절대로 .keep 파일을 임의대로 만들지 마시기 바랍니다. 포티지가 keepdir 동작을 변경할 때, 임의로 파일을 만드는 행위가 패키지를 깨지게 할 수도 있습니다.
econf 필요한 경로변경 (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir)과 함께 ./configure를 수행합니다. econf를 호출했을 때 이들을 지정하여 ./configure에 추가 인자를 선택적으로 넘길 수 있으며, 사용자는 필요한 경우 환경변수 EXTRA_ECONF 를 설정할 수 있습니다. 옵션들은 설정을 위해 주어진 순서의 역순으로 전달됩니다. 다시 말해, 전달된 첫번째 인자는 항상 우선순위가 가장 나중으로 될 것입니다.
einstall 필요한 경로변경 (prefix, datadir, mandir, infodir, datadir, sysconfdir, localstatedir)과 함께 make install을 수행합니다. 다시 말해, einstall을 호출하면 이들을 지정하여 make 명령으로 추가 인자를 넘길 수 있습니다. 패키지를 설치하기 위해 준비된 방법은 emake install DESTDIR="${D}" 명령을 통해서지 einstall을 통한 방법이 아님을 인지하여 주시기 바랍니다. 이 명령은 단지 깨진 make 퍄일에 우선하는 대체용일 뿐입니다.
die 현재 프로세스를 중단하도록 합니다. 주어진 인자를 이유로 사용하여 사용자에게 알려줍니다. 단일 함수에서 이것을 한번 이상 호출한다면 메세지를 전달하는 것을 게을리하지 마시기 바랍니다. 어떤 패키지에서 실패가 발생했는지 알 수 없다면 이를 추적하는 것이 어렵기 때문입니다.
elog 사용자에게 중요한 내용을 알려줍니다. elog에 주어진 인자는 사용자가 보게 될 메시지 입니다. "**************************************" 와 같은 배너를 보여주기 위해 elog를 사용하지 마시기 바랍니다. elog를 사용한다는 것은 사용자의 주의를 충분히 끄는 것입니다. 메시지는 ELOG 시스템을 사용하여 기록됩니다.
einfo 도움이 되지만 로그될 필요가 없는 그다지 중요하지 않은 메시지를 보여줍니다.
eutils.eclass에서 제공하는 도우미 함수

ebuild에서는 "eutils" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 inherit eutils가 파일에 있는지 확인해보셔야 합니다.

함수 용도
epatch 이 함수는 patch의 친숙한 대체 대상처럼 동작하며 .bz2, .gz, .zip 그리고 순수 텍스트 패치와 함께 동작합니다. -p 옵션 뿐만 아니라 EPATCH_OPTS에 명시적으로 지정될 필요가 있는 어떤 옵션도 지정할 필요가 없습니다. 이 함수는 파일이나 디렉>터리 둘 중 하나가 인자로서 사용됩니다. 디렉터리를 사용한다면 "??_${ARCH}_..."와 같은 모양새의 모든 패치가 적용될 것입니다. 이 패치들을 적용하려면 실행중인 아키텍처와 일치하거나, 이름에 "_all_"이 들어가거나 EPATCH_FORCE가 반드시 "yes"로 설정될 필요가 있습니다.
gen_usr_ldscript 이 함수는 /lib에 있는 동적 라이브러리에 대해 /usr/lib에 링커 스크립트를 생성합니다. 이는 /lib에 .so가 있고 /usr/lib에 .a 가 존재할때 연결 문제를 수정합니다.
edos2unix 이 함수는 dos2unix 바이너리처럼 동작합니다.
egetent egetent는 리눅스용 getent나 Mac OS X(R)용 nidump의 래퍼 처럼 동작합니다.
enewuser 새 사용자를 만듭니다. 이 함수는 사용자 이름 인자를 필수로 사용하며 몇몇 추가적 인자가 지정될 수 있습니다: $2 에는 UID가 들어가는데 -1을 전달하면 그 다음 사용가능한 ID를 전달하게 됩니다. $3에는 쉘이 들어가며 -1은 기본값을 의미합니다. $4 에는 홈 디렉터리가 들어가는데 /dev/null이 기본값이 되며, $5 에는 사용자가 들어가게 될 그룹이 들어가는데 빈 값이 기본값이며, $6에는 useradd에 전달하고 싶은 추가적인 옵션이 들어갈 수 있습니다.
enewgroup 새 그룹을 추가합니다. 이 함수는 그룹 이름을 필수로 사용합니다. 추가적인 두번째 인자는 그룹에 지정된 GID를 부여합니다.
make_desktop_entry 데스크톱 엔트리를 만듭니다. 첫번째 인자는 바이너리의 경로를 포함합니다. 선택적으로 두번째 인자는 아이콘의 이름입니다. 기본값은 ${PN}; 입니다. 세번째 인자는 /usr/share/pixmaps에 상대적인 경로를 포함하거나 전체 경로를 포함할 수 있습니다. 기본값은 ${PN}.png; 입니다. 네번째 인자는 프로그램 카테고리를 포함할 수 있고, 다섯번째 인자는 선택적으로 프로그램의 시작 경로를 포함할 수 있습니다.
check_license 사용자가 수락할 라이선스를 표시합니다. 만약 인자가 지정되지 않았다면 ${LICENSE}에 지정된 라이선스가 사용됩니다.
unpack_pdv pdv가 생성한 아카이브를 풉니다. 첫번째 인자는 풀어낼 파일이 반드시 들어가야 하며 두번째 인자는 strace -elseek ${file}과 "4"라는 값을 전달할 lseek(3,-4,SEEK_END)"와 같은 것을 통해 수동 생성될 "off_t"가 들어가게 됩니다.
unpack_makeself makeself가 생성한 아카이브를 풉니다. 풀 파일이름이 인자로서 필요합니다.
cdrom_get_cds CD를 가져오려 시도합니다. 인자에 지정한 파일들은 시스템에 나타나며 ${CDROM_ROOT}에 마운트됩니다.
cdrom_load_next_cd 첫번째 CD에 대한 작업이 끝났다면 다음 CD를 넣도록 합니다. 이 함수가 값을 반환하면 ${CDROM_ROOT}는 다음 CD를 가리킬 것입니다.
strip-linguas 이 함수는 LINGUAS 변수에 패키지에서 지원할 수 있는 함수의 인자로 지정한 언어만 들어있는지를 확인합니다. 첫번째 인자가 -i라면, 지정된 디렉터리에 있는 .po 파일들의 목록이 만들어지고, 리스트들의 교집합이 사용될 것입니다. 첫번째 인자가 -u라면, 지정된 디렉터리의 .po파일 목록이 만들어지고, 전체 리스트들의 모든 항목을 사용할 것입니다.
flag-o-matic.eclass에서 제공하는 도우미 함수

ebuild에서는 "flag-o-matic" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 {{{#0000ff inherit flag-o-matic }}}이 파일에 있는지 확인해보셔야 합니다. 어떤 컴파일러의 설정이라도 직접 수정하지 않는 것이 좋으며, 문제를 일으>키는 플래그를 걸러내는 일련의 동작을 수행하기 위해서라면 flag-o-matic을 대신 사용해주시는 것이 좋겠습니다.

함수 용도
filter-flags 이 함수는 C(XX)FLAGS의 일부 플래그를 제거합니다. 일치하는 완전한 플래그에만 해당됩니다.
append-flags 이 함수는 존재하는 C(XX)FLAGS 변수에 추가 플래그를 추가합니다.
replace-flags 이 함수는 C(XX)FLAGS에 존재하는 플래그중 하나가 들어간 두번째 인자를 지정된 첫번째 인자로 대체합니다.
replace-cpu-flags 두 인자가 필요합니다. 주어진 mtune/march/mcpu 값을 새로운 값으로 바꿉니다 (다음과 같이 될 것입니다: replace-cpu-flags 'i686' 'i586' 은 -mtune/-march/-mcpu=i686 을 -mtune/-march/-mcpu=i586으로 바꿀 것입니다).
strip-flags 모든 플래그를 없애지만, ALLOWED_FLAGS에 지정된 것들은 제외합니다.
strip-unsupported-flags 실행중인 GCC 버전에 의해 지원되지 않는 어떤 플래그든지간에 C(XX)FLAGS에 있으면 없앱니다.
get-flag 플래그를 찾아서 값을 출력합니다.
is-flag 현재 C(XX)FLAGS 에 설정되어 있는 플래그라면 true를 반환합니다. 완전히 일치하는 경우에만 수행됩니다.
append-ldflags 이 함수는 존재하는 LDFLAGS변수에 추가 플래그를 추가합니다.
filter-ldflags LDFLAGS로부터 완전히 일치하는 지정된 플래그만을 제거합니다.
fstack-flags -fstack-protector와 -fstack-protector-all의 적용을 억제하는 -fno-stack-protector를 붙입니다.
toolchain-funcs.eclass에서 제공하는 도우미 함수

ebuild에서는 "tollchain-funcs" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 {{{#0000ff inherit toolchain-funcs}}} 가 파일에 있는지 확인해보셔야 합니다. 어떤 컴파일러나 binutils의 설정을 직접 명시적으로 지정하지 않는 >것이 좋으며 컴파일러나 binutils를 지정하려면 toolchain-funcs를 사용해주시는 것이 좋겠습니다.

아래 함수들에 대한 사용 목적은 크로스 컴파일링의 지원과 icc 컴파일러를 위한 것입니다. 이 함수들은 gcc, g++, ld, ranlib 또는 아래의 도구들 중 하나를 사용할 때 사용될 것입니다. 자동 설정 도구를 사용하는 일반적인 패키지들은 크로스 컴파일을 자동으로 감지하며 다음 함수를 필요로 하지는 않습니다.

함수 용도
tc-getAR 아카이버의 이름을 반환합니다.
tc-getAS 어셈블러의 이름을 반환합니다.
tc-getCC C 컴파일러의 이름을 반환합니다.
tc-getCXX C++ 컴파일러의 이름을 반환합니다.
tc-getLD 링커의 이름을 반환합니다.
tc-getNM 심볼/객체 검사 도구의 이름을 반환합니다.
tc-getRANLIB 아카이버 인덱서의 이름을 반환합니다.
tc-getF77 포트란 컴파일러의 이름을 반환합니다.
tc-getGCJ 자바 컴파일러의 이름을 반환합니다.
tc-getBUILD_CC 빌드를 위한 C 컴파일러의 이름을 반환합니다.
gcc-fullversion $($CC -dumpversion)으로부터 나오는 버전을 반환합니다.
gcc-version 버전을 반환하지만 <major>.<minor> 형식으로만 나옵니다
gcc-major-version 메이저 버전을 반환합니다.
gcc-minor-version 마이너 버전을 반환합니다.
gcc-micro-version 마이크로 버전을 반환합니다.

ebuild 파일 작성 규칙

ebuild파일이 단지 쉘 스크립트이기 때문에, ebuild파일을 편집하려면 편집기의 쉘 스크립트 모드를 사용하는 것이 좋습니다. 적절한 들여쓰기를 하는 것이 좋으며, 들여쓰기에는 공백 문자입력이 아닌 탭을 사용합니다. 편집기가 탭 간격이 4칸으로 조정되어 있는지를 확인합니다. 그리고 환경변수 주변에 중괄호를 감쌌는지 항상 확인합니다. 예를 들어 그냥 $P가 아니라 ${P} 입니다.

긴 줄에 대해서는 '\'로 마무리 합니다. 따라서


코드 예제 2.3: ebuild 편집을 위해 vimrc 설정하기
au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab


이맥스를 사용한다면, app-emacs/gentoo-syntax(GNU Emacs용)나 app-xemacs/gentoo-syntax (XEmacs 용) 둘 중 하나를 이머지 하는 것이 좋습니다. 이 패키지들은 자동 들여쓰기와 ebuild에 대한 문법 강조 그리고 기타 젠투에 특화된 파일 유형을 위한 이맥스 메이저 모드를 제공합니다.

나노를 사용한다면, 운이 참 좋은 것입니다! 단지 /etc/nanorc를 편집하여 ebuild참조 섹션에 대한 주석을 해제하기만 하면 됩니다.

USE 변수

USE 변수의 용도는 포티지 설정을 전체적으로 설정할 수 있게 하고 추가적 빌드 타임에 어떤 기능을 자동으로 활성화 혹은 비활성화 할 수 있게끔 합니다. 예를 들어보도록 합니다. 여러분은 그놈 팬이고 선택적으로 그놈을 지원할수 있는 옵션을 ebuild에 넣고 싶어합니다. 이 경우 /etc/make.conf의 USE 변수에 gnome 을 넣고 USE 변수에 그놈이 설정되지 않았는지 확인합니다. 젠투 리눅스는 여러분이 원하는 방식으로 정확하게 설정된 시스템을 가질 수 있도록, 압도적으로 많은 USE 옵션을 지니고 있습니다.


참고: USE 변수의 설정을 해제한다면(예를 들어, USE로부터 gnome을 제거한다면), 포티지에게 그놈을 위한 선택적 빌드 타임 지원을 비활성화 하라고만 지시할 것입니다. 그러나 그놈을 필요로 하는 ebuild를 emerge 한다면, 해당 패키지는 기대하는 바와 같이 그놈 지원을 명백히 활성화 할 것입니다. 이는 또한 그놈이 설치되지 않았다면 자동으로 (의존성에 따라) 설치될 것임을 의미합니다. 이렇기 때문에 "실제로" emerge를 수행하기 전에 emerge --pretend를 수행하는 것은 좋은 방법입니다. 이 방법을 통해 여러분은 정확하게 어떤 패키지를 얻게 되는지 항상 알게 될 것입니다!


여러분의 ebuild에서 use <variable> 명령을 통해 USE변수에 설정이 되었는지 검사할 수 있습니다. 보통 이 명령을 다음처럼 사용할 것입니다:


코드 예제 2.4: USE 플래그가 설정되어 있는지 찾아보기
if use X; then

     # Commands specific to X...
fi


USE 변수는 또한 의존성을 설정하기 위해서도 사용됩니다. 예를 들어, 몇몇 USE 변수값이 설정되었을때 패키지를 요구하는 것만 원할지도 모릅니다. 이는 ebuild의 DEPEND 변수에서 flag? ( mycat/mypackage ) 문법을 사용하여 해결할 수 있습니다. 이 경우 mycat/mypackage는 flag가 USE에 있을때만 필요합니다. 또한 어떤 USE 플래그가 설정되었을때와 어떤 USE 플래그가 설정되지 않았을때 어떤 의존성이 사용될지 flag? ( mycat/mypackage ) 와 !flag? ( othercat/otherpackage )로 지정할 수도 있습니다. 이 경우 flag가 설정되어 있지 않았다면 othercat/otherpackage가 mycat/mypackage 대신 사용될 것입니다. 배시의 if를 사용하는 것이 아니라 ebuild의 이 문법을 사용했는지 확인해보시기 바랍니다. Bash 조건문은 포티지의 의존성 캐싱과 혼동되며, 배시 문법을 사용하면 ebuild를 깨지게 할 것입니다.

여기에 USE를 사용하는 중요한 요령이 있습니다. 대부분, 패키지에는 설정 과정을 수행하기 위해 ./configure 스크립트를 가질 것입니다. 일반적으로 ebuild가 ./configure를 사용하면, 어떤 추가적인 빌드타임 기능성은 ./configure 명령으로 적당한 인>자를 전달하여 활성화되거나 비활성화될 것입니다. 여기에 이런 것들을 조작하는 가장 좋은 방법이 있습니다.


코드 예제 2.5: USE 설정 기반 조건문
DEPEND="X? ( >=x11-base/xfree-4.3 )

mysql? ( >=dev-db/mysql-3.23.49 )
apache2? ( >=net-www/apache-2 )
!apache2? ( =net-www/apache-1* )"

src_compile() {
    econf \
    $(use_enable X x11) \
    $(use_enable mysql)
    emake || die "Error: emake failed!"

}


이 접근은 매우 괜찮은 결과를 가져옵니다. mysql이나 X를 위한 기본 설정(활성화/비활성화)이 어떤지에 대해 걱정할 필요가 없고, econf에게 USE 변수 값들을 기반으로 원하는 것들을 명확하게 알려줍니다. 가독성 측면에서도 조금 깔끔하다는 점은 굳이 언급하지 않겠습니다.

가끔 ebuild에는 선택적인 특징들의 충돌이 있을 것입니다. 이러한 충돌을 검사하고 오류를 반환하는 것은 가능한 해결책이 아닙니다. 대신 다른 것들중 한가지 특징에 대해 반드시 선택하여야 합니다. 이렇게 되면, 업스트림과 상의(보통 기본적으로 쓰는 것이 무엇이냐)하거나, 좀더 일반적인 기능을 제공하는 옵션을 고려하거나, 동전 뒤집기를 합니다. msmtp ebuild로부터 한가지 예를 들어보도록 하겠습니다. 패키지에는 SSL과 GnuTLS, SSL과 OpenSSL 혹은 SSL을 모두 사용하지 않는 방식을 사용할 수 있습니다. 왜냐면 GnuTLS는 OpenSSL에 비해 더 많은 기능을 지니고 있는데, 이게 장점입니다:


코드 예제 2.6: 충돌 기능 다루기
src_compile() {

    local myconf

    if use gnutls ; then
        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
    elif use ssl ; then
        myconf="${myconf} --enable-ssl --with-ssl=openssl"
    else
        myconf="${myconf} --disable-ssl"
    fi

    econf \
        # Other stuff
        ${myconf}

    emake || die "make failed"
}


USE 변수에 대한 최신 테이블을 계속 보시려면, 이 곳으로 가시기 바랍니다.

파일 시스템 위치

FHS에 대한 소개

젠투 리눅스에서 사용하는 파일 시스템 배치 표준은 File system Hierarchy Standard의 약자인 FHS를 거의 따릅니다. 표준에 대한 간단한 설명은 여기에 있습니다. 완전한 명세서를 보시려면 http://www.pathname.com/fhs/로 가시기 바랍니다.


참고: /opt 계층은 FHS의 섹션 3.12 에 있습니다. 섹션 4.4 에서는 /usr/X11R6 디렉터리에 대해 다룹니다. KDE와 GNOME은 특별히 다루어지지 않았고 현재 버전의 FHS에서 언급되지도 않았습니다.


시스템에 패키지를 적용하는 방법

보통 패키지가 autoconf와 automake를 사용한다면 기본 설치 대상경로는 대부분 몇몇 예외를 제외하고 올바릅니다:

  • 프로그램을 /bin, /sbin, /usr/bin, 혹은 /usr/sbin에 설치한다면 프로그램의 관련 맨 페이지는 /usr/share/man 트리에 설치될 것입니다. 이는 종종 ebuild에서 ./configure --mandir=/usr/share/man을 지정하여 수행할 수 있습니다.
  • GNU info 파일은 X11, 그놈, KDE와 관련된 프로그램이나 도구에 대한 것일지라도 항상 /usr/share/info 에 설치될 것입니다. 여기서 참고할 것은 /usr/share/info 는 오직 GNU info 파일이 위치하게 될 공식 경로입니다. 대부분의 ./configure 스크립트가 /usr/info에 GNU info 파일을 설치하는 것을 기본으로 하는데, 종종 ./configure에 --infodir=/usr/share/info 인자를 붙여 호출할 필요가 있습니다.
  • 문서 파일들은 /usr/share/doc에 설치되며, 제각각의 프로그램에 대하여 하위 디렉터리에 프로그램의 이름과 버전, 리비전을 반영합니다. 이는 그놈, KDE, X11 그리고 콘솔을 기반으로 하는 모든 프로그램에 적용됩니다. 그러나 어떤 프로그램은 추가적인 문서를 설치할 것이고 그들 자신의 고유목적에 따라 /usr/share 계층으로 지원 파일을 넣을 것입니다.
  • X11과 관련된 프로그램과 라이브러리는 항상 /usr에 설치되겠지만 /usr/X11R6로 바로 들어가는 것은 아닐 것입니다. /usr/X11R6 계층을 X 윈도 시스템 버전 11 릴리즈 번호 6을 위해 예약하였습니다. 이는 아마도 몇몇 다른 배포판이 그렇게 했다기보단 FHS의 문자적인 해석에 비중을 두기 때문인지도 모릅니다.
  • 그놈과 KDE 프로그램과 같은 것들은 항상 /usr 로 설치될 것입니다.


중요: 몇몇 배포판은 그놈과 KDE를 /opt로 설치하는 것을 선택합니다. 실제로 그들 파일을 어디에 설치할 것인가에 대한 내용이 이들 데스크탑 환경에 대해 표준으로 존재하지 않습니다. 단순성과 일관성 고려측면에서, 젠투는 모든 KDE와 그놈 패키지를 선택하기 위해 /usr 디렉터리를 선택했습니다.


일반적으로, /usr 트리에 이들 파일을 설치하는 ebuild를 가지고 있을 것입니다. 몇몇 프로그램은 혼동을 야기하는 그놈이나 KDE, X11 라이브러리를 포함하거나 제외하여 컴파일하고 링크할 수 있습니다. 해결책이 있다면 모호성을 방지하기 위해 모두 /usr에 설치하고 ebuild 저작자를 위해 복잡성을 줄이는 것입니다. 프로그램의 파일이 설치될 위치는 특정 USE 변수의 존재와 누락에 관련되어서는 안될 것입니다. 따라서, 포티지 트리의 ebuild는 거의 항상 배타적으로 /usr 계층에 설치합니다.


참고: 젠투 리눅스에서 /opt 디렉터리는 바이너리만 존재하는 패키지를 위해 예약되었습니다. 그 예로 mozilla-bin, acroread, netscape 그리고 realplayer가 포함됩니다. 여기에 설치될 패키지는 보통 /etc/env.d/foo와 같은 파일을 필요로 할 것입니다. 이를 통해 경로와 추가 변수를 환경에 포함할 수 있습니다. /etc/env.d에 대해 더 알아보시려면 [이 문서] 를 방문해보시기 바랍니다.


포티지 스크립트와 유틸리티

공용 스크립트

이 스크립트는 시스템 관리자가 패키지를 설치하고 제거하며 패키지 데이터베이스를 유지하는데 사용합니다.

ebuild는 포티지 시스템의 주 엔진입니다. 이는 패키지 풀기, 컴파일, 설치, 병합 그리고 병합해제와 같은 모든 주된 작업을 수행합니다. 이는 다음 명령으로 호출됩니다: ebuild path/to/package.ebuild command. 사용할 수 있는 명령은 다음과 같습니다:

명령 설명 관련 ebuild 함수
setup* ebuild가 수행되기 전에 필요한 어떤 잡다한 명령들을 수행합니다 pkg_setup
depend 패키지를 빌드하는데 필요한 의존성을 표시합니다 N/A
merge* 시스템에 패키지를 풀고, 컴파일, 설치 그리고 병합합니다 N/A
qmerge* 이미 시스템에 패키지가 풀리고, 컴파일 설치 과정이 실행되었다 가정한 상태에서 파일 시스템에 패키지를 병합합니다 N/A
unpack* 작업 디렉터리로 소스 타르볼을 풉니다 src_unpack
compile* 패키지를 컴파일 합니다 src_compile
rpm 패키지로부터 RPM을 만듭니다 N/A
package 젠투의 tbz2 패키지를 만듭니다 N/A
prerm* 패키지를 제거하기 이전 단계를 실행합니다 pkg_prerm
postrm* 패키지를 제거하고 난 단계를 실행합니다 pkg_postrm
preinst* 패키지를 설치하기 이전 단계를 실행합니다 pkg_preinst
postinst* 패키지를 설치하고 난 단계를 실행합니다 pkg_postinst
config 패키지가 병합되면 기본 설정내용으로 설정합니다 pkg_config
touch* 패키지의 각각의 소스 아카이브에 대한 mtimes를 새로 고칩니다 N/A
clean* 패키지의 작업 디렉토리를 비웁니다 N/A
fetch* 패키지 소스 타르볼을 가져옵니다 N/A
manifest* 패키지에 대한 매니페스트를 만듭니다 N/A
test* 패키지에 대한 자체 테스트 루틴을 실행합니다 src_test
install* 이미지 디렉터리에 패키지를 설치합니다 src_install
unmerge 파일 시스템으로부터 패키지를 병합해제합니다 N/A


참고: 별표 문자(*)와 함께 있는 명령은 개발자들만 사용합니다.


emerge는 재귀적으로 패키지와 파일 시스템의 모든 의존요소를 병합합니다. 이 명령은 많은 옵션들이 있습니다. 목록을 보려면 emerge --help를 입력합니다.

env-update는 설치된 패키지가 변경한 내용이 들어있는 설정 파일들을 새로 고칩니다 (/etc/ld.so.conf와 /etc/profile.env도 포함하지만 제한적임)

비공개 스크립트와 명령들

일반적인 작업을 수행할 ebuild 파일에서 사용할 수 있는 스크립트 입니다.

기초적인 분들을 위해 /usr/lib/portage/bin에 있는 스크립트에 대해 보도록 하겠습니다.

명령 기본값 설명 예제
diropts -m0755 dodir을 실행할때 사용하는 옵션을 설정합니다 diropts -m0750
dobin N/A 지정된 바이너리를 DESTTREE/bin에 설치합니다 dobin wmacpi
docinto "" dodoc이 사용하는 관련 하위 디렉터리 (DOCDESTTREE)를 설정합니다 docinto examples
dodir N/A ${D}를 명백하게 다루는 디렉토리를 만듭니다 dodir /usr/lib/newpackage
dodoc N/A 지정된 파일을 패키지의 문서 디렉토리 (/usr/share/doc/${PF}/DOCDESTTREE)로 설치합니다(docinto 참조) dodoc README *.txt
doexe N/A EXEOPTIONS (exeopts 참조) 모드로 지정된 파일을 EXEINTO (exeinto 참조)가 정의한 PATH로 설치합니다. doexe ${FILESDIR}/quake3
dohard N/A ${D}를 명백하게 다루는 하드링크를 만듭니다 dohard ls /bin/dir
dohtml N/A 지정한 파일과 디렉터리를 /usr/share/doc/${PF}/html에 설치합니다 dohtml -r doc/html/*
doinfo N/A 지정한 파일을 /usr/share/info에 설치하고, gzip으로 압축합니다 doinfo doc/*.info
doins N/A INSOPTIONS (insopts 참조) 모드로 지정된 파일을 INSDESTTREE(insinto 참조)에 설치합니다 doins *.png icon.xpm
dolib N/A 지정된 라이브러리를 0644모드로 DESTTREE/lib에 설치합니다 dolib *.a *.so
dolib.a N/A 지정된 라이브러리를 0644모드로 DESTTREE/lib에 설치합니다 dolib.a *.a
dolib.so N/A 지정된 라이브러리를 755모드로 DESTTREE/lib에 설치합니다 dolib.so *.so
doman N/A 지정된 파일을 파일의 접미문자에 따라 /usr/share/man/manX에 설치합니다 (file.1 은 man1에 복사됨) doman *.1 *.5
dosbin N/A 파일을 DESTTREE/sbin에 설치하고, 실행가능한지 확인합니다 dosbin ksymoops
dosym N/A ${D}를 명백하게 다루는 심볼릭 링크를 만듭니다 dosym gzip /bin/zcat
emake N/A MAKEOPTS로 make를 실행합니다. 어떤 패키지는 병렬로 만들어질 수 없어서 대신 emake -j1을 사용합니다. 패키지를 만들기 위해 전달할 추가 인자가 필요하다면, emake 명령에 붙여주기만 하면 됩니다. 사용자들은 emake에 추가 플래그를 넘겨주기 위해 EXTRA_EMAKE 환경 변수를 설정할 수 있습니다. emake
exeinto / doexe명령을 위해 루트 (EXEDESTTREE)를 설정합니다 exeinto /usr/lib/${PN}
exeopts -m0755 doexe를 실행할 때 사용하는 옵션을 설정합니다 exeopts -m1770
fowners N/A ${D}를 명백하게 다루는 chown 명령을 통해 지정된 소유규칙을 지정된 파일에 적용합니다. fowners root:root /sbin/functions.sh
fperms N/A ${D}를 명백하게 다루는 chown 명령을 통해 지정된 권한을 지정된 파일에 적용합니다. fperms 700 /var/consoles
insinto /usr doins명령을 위해 루트 (INSDESTTREE)를 설정합니다 insinto /usr/include
insopts -m0644 doins를 실행할 때 사용하는 옵션을 설정합니다 insopts -m0444
into /usr 모든 'do' 명령들 (dobin, dolib, dolib.a, dolib.so, domo, dosbin)을 위해 타겟 접두 경로(DESTTREE)를 설정합니다. into /
libopts -m0644 dolib를 실행할때 사용하는 옵션을 설정합니다 libopts -m0555
newbin N/A 지정된 바이너리를 명백하게 두번째 인자로 이름을 바꿔 설치하는 dobin의 래퍼입니다 newbin ${FILESDIR}/vmware.sh vmware
newdoc N/A 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 dodoc의 래퍼입니다 newdoc README README.opengl
newexe N/A 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 doexe의 래퍼입니다 newexe ${FILESDIR}/xinetd.rc xinetd
newins N/A 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 doins의 래퍼입니다 newins ntp.conf.example ntp.conf
newman N/A 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 doman의 래퍼입니다 newman xboing.man xboing.6
newsbin N/A 지정된 파일을 명백하게 두번째 인자로 이름을 바꿔 설치하는 dosbin의 래퍼입니다 newsbin strings strings-static
prepall N/A prepallman, prepallinfo 그리고 prepallstrip를 실행합니다. 또한 /opt/*/lib, /lib, /usr/lib 그리고 /usr/X11R6/lib 에 있는 모든 라이브러리가 실행가능한지 확인합니다. 또한 일부 흩어진 aclocal 매크로를 /usr/share/aclocal에 옮겨줍니다 prepall
prepalldocs N/A 이것이 수행하는 동작이 포티지 버전이 바뀌면서 변경되어 새로운 ebuild에서는 이 함수를 사용하지 않는 것이 좋습니다. prepalldocs
prepallinfo N/A /usr/share/info의 모든 info 파일을 재귀적으로 gzip으로 압축합니다 prepallinfo
prepallman N/A /opt/*/man/*, /usr/share/man/*, /usr/local/man/*, /usr/X11R6/share/man/* 에 있는 모든 맨 페이지를 gzip으로 압축하고 일부 심볼릭 링크 경로를 확실하게 수정합니다. prepallman

패키지 의존성

의존성이 중요한 이유

포티지는 소스로부터 어떤 하나의 프로젝트 (프로그램이나 라이브러리) 를 빌드하는 통합적인 수단을 제공해주는 편의 스크립트의 그 이상입니다. 또한 ebuild에 지정하여 처리할 필요한 어떤 의존요소를 가져오고 설치할 것입니다.

공식 ebuild에서는 모든 의존요소가 이미 지정되어 있어 emerge net-www/mozilla/mozilla-1.0을 실행하면, 포티지는 모질라를 빌드하고 실행하는데 필요한 모든 라이브러리가 모질라를 빌드하기 전에 적당하게 설치하는 것을 확실하게 할 것입니다.

포티지는 또한 빌드타임 의존 요소와 실행시간 의존 요소를 구분합니다. (경고: 현재로서는, 포티지는 모든 빌드타임, 실행시간 의존요소와 나머지의 것들을 설치합니다. 다음 단계에서, 설치 내용을 손 볼 가능성이 있어, 실행 시간 의존 요소만 설치된 채로 남아있게 됩니다)

ebuild 파일(DEPENDS 요소)에 의존성을 지정하는 방법

foo-x.y.z.ebuild에 있는 DEPEND 변수는 포티지에게 어떤 패키지를 빌드할 필요가 있는지를 알려줍니다. RDEPEND 변수는 foo를 실행하는데 필요한 패키지를 지정합니다. RDEPEND 는 DEPEND와 같다 해도 명시적으로 설정되어야 하는데 DEPEND에 기본으로 지정되>어 있는 것이 나중에 포티지로부터 제거되도록 계획되어 있기 때문입니다.


코드 예제 5.1: Depend 예제
DEPEND="virtual/opengl

    dev-libs/libxml2"
RDEPEND="${DEPEND}"


이는 foo-x.y.z를 빌드하도록 포티지에게 일러줍니다. virtual/opengl 과 dev-libs/libxml2 패키지가 필요합니다. 여기에는 opengl이나 libxml2의 어떤 버전이 필요한지 알려주진 않으며 이는 "실행할 어떤 것"을 의미합니다.

이 "실행할 것"이 물론 조금 무섭(?)기도 하고, 일반적으론 동작하지 않을 것입니다. 그러나 라이브러리라면, 항상 100% 바이너리 호환을 지니게 하는 노력이 매우 어렵지만, 실제적으론 동작합니다. 다른 라이브러리에 대해, 물론 버전 의존 요소를 지정할 수 있습니다.


코드 예제 5.2: 버전 예제
>=sys-apps/bar-1.2
=sys-apps/baz-1.0


>= 와 =는 무얼 원하는지에 대한 판단을 수행합니다. sys-apps/bar는 버전 1.2 이상이면 됩니다 (이 얘기는 sys-apps/bar-2.0이면 된다는 얘깁니다). 그리고 sys-apps/baz의 버전은 1.0만 허용됩니다. 버전 개요에 대해 더 많이 알고 싶다면 ebuild 파일 이름 짓기에 있는 섹션을 보시기 바랍니다.

버전 의존 요소를 지정하는 다른 방법은 다음과 같습니다:


코드 예제 5.3: 버전 의존요소 지정하기
~sys-apps/qux-1.0

=sys-apps/foo-1.2*

!sys-libs/gdbm


~sys-apps/qux-1.0 는 qux-1.0의 최신 포티지 리비전을 선택할 것입니다.

=sys-apps/foo-1.2* 는 1.2시리즈의 최신 멤버를 선택하지만 1.3이상은 무시할 것입니다. 이 얘기는 foo-1.2.3 와 foo-1.2.0는 유효하지만, foo-1.3.3, foo-1.3.0 그리고 foo-1.1.0는 그렇지 않다는 것입니다. 이때 문제가 될 수 있는 foo-1.22.3 또한 일치할 것이라는 것 알아두 시기 바랍니다.

!sys-libs/gdbm 는 이미 gdbm이 이머지 되었을 때 이 패키지가 이머지 되는 것을 막을 것입니다.

중요한 참고

DEPEND와 RDEPEND변수에 잘못 지정하는 많은 경우들이 있습니다. 의존요소를 작성할 때 따라야 할 중요한 점들이 있습니다.

  • CATEGORY는 항상 포함합니다.

예를 들어 >=x11-libs/gtk+-2지, >=gtk+-2가 아닙니다.

  • >= 의존 요소에는 별표 문자(*)를 넣지 않습니다.

예를 들어 >=x11-libs/gtk+-2*보다는 >=x11-libs/gtk+-2가 되어야 합니다.

  • 메타패키지를 의존 요소로 절대 걸지 않습니다.

다시 말해 항상 libgnome과 같은 특정 라이브러리에 의존하는 gnome-base/gnome을 의존 요소로 걸면 안됩니다.

  • 한 줄에 하나의 의존 요소

한 줄에 여러 의존요소를 적지 않습니다. 읽기 괴랄해지고 파악하기 어렵습니다.

  • GTK: GTK+1 프로그램을 위해 항상 =x11-libs/gtk+-1.2*를 사용합니다.

덧붙여 여러분의 패키지에 모든 의존 요소가 완전히 작성되었는지 확인하는데 중요한 사항들입니다.

  • 설치된 바이너리/라이브러리를 살펴봅니다

DT_NEEDED 항목을 나열해보기 위해 scanelf -n 과 같은 도구를 사용합니다.

  • configure.in이나 configure.ac를 살펴봅니다

패키지를 검사하기 위해 이곳을 봅니다. pkg-config checks나 특정 버전을 확인하는 AM_* 함수를 사용하면 찾을 내용을 살펴볼 수 있습니다.

  • 포함된 .spec 파일을 살펴봅니다

의존요소를 바로 볼 수 있는 방법은 관련된 의존 요소가 포함된 .spec파일을 찾아보는 것입니다. 그러나 의존 요소들의 결정적으로 완벽한 목록이 될 거라고 믿지는 마시기 바랍니다.

  • 패키지의 README와 INSTALL를 읽습니다

패키지를 빌드하고 설치하기 위한 유용한 정보가 들어있기도 합니다.

  • pkg-config, 문서 생성 프로그램 등의 비 바이너리 의존성을 상기합니다

보통 빌드 과정에서는 intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc 등과 같은 의존 요소를 필요로 합니다. 명확하게 명시되었는지 확인해보도록 합니다.

DEPEND 요소에 대한 최신 세부내용을 보시려면 ebuild의 맨 페이지 섹션 5를 참고바랍니다: man 5 ebuild.

테스트 및 배포

ChangeLog

ebuild를 새로 받을(혹은 새로 작성할) 때마다 이에 대한 ChangeLog를 새로 고쳐(혹은 새로 만들어)야 합니다. skel.ChangeLog에는 기반으로 사용할 수 있는 간단한 ChangeLog가 있습니다.

ChangeLog의 목적은 무엇을 했는지, 왜 했는지, 누가 했는지를 문서화 하는 것입니다. 이를 통해 개발자와 사용자가 변경사항을 쉽게 추적할 수 있습니다.

ChangeLog는 기본적으로 사용자에게 초점이 맞춰져 있기 때문에, 이 시점에서 반드시 짧게 작성하는 것을 유지해야 하며, 내부의 기술적 세부내용에 대해 장황하게 늘어놓는 것을 삼가해야 합니다.

여러분의 ebuild를 따로 저장하기

ebuild를 테스트 할 수 있게 하고, 포티지가 이것을 알아채게끔 하려면, 기존의 알려진 디렉터리에 이것(ebuild)들을 넣어야 합니다. 포티지는 /etc/make.conf에 설정할 수 있는 PORTDIR_OVERLAY변수를 사용할 것입니다. 사용할 디렉토리를 이 변수에 (/usr/local/portage 처럼) 설정할 필요가 있습니다.

이 디렉토리에 /usr/portage와 같은 구조 (와 카테고리) 를 사용하여야 합니다.

PORTDIR_OVERLAY를 사용할 때, ebuild는 시스템에 남아있게 되고, emerge sync를 수행해도, 포티지가 이들이 남아있음을 인지합니다.

패키지 시험

이 패키지가 동작하는지 어떻게 테스트 할 것인지를 생각해보도록 합니다. 가끔 개발자는 패키지의 기본적인 기능성을 테스트 하기 위해 이미 들어간 make test나 make check루틴을 보유합니다. 만약 이렇다면 FEATURES=test ebuild foo-x.y.z.ebuild test를 실행할 때 make test나 make check루틴을 실행할 것입니다. 이게 깨졌다면 이게 제대로 동작하도록 고쳐보려 할 것입니다 (그리고 업스트림 개발자에게 패치를 제공할 것입니다).

이 상황이 고려되지 않았다면 src_test 루틴을 ebuild에 넣는 것을 고려해보도록 합니다. src_install루틴을 수행하기 전에 이것을 먼저 실행할 것이고 여러 아키텍처에서 프로그램이 동작하는 것을 시험하는데 매우 도움이 될 수 있을 것입니다. 여기에 루틴을 추가 하여 패키지의 기능에 대한 지식을 필요로 하지 않는다면 아키텍처 개발자는 퍽이나 좋아라 할 것입니다.

ebuild의 일반적인 요구사항을 염두에 두기 바랍니다. src_test루틴은 반드시 대화형이어선 안됩니다. 만약 시험 루틴이 다른 패키지에 의존한다면 test USE플래그를 사용하여 선택적 컴파일 시간의 DEPENDancy를 지정할 수 있도록 합니다. 또한, src_test 루틴은 사용자들이 포티지의 실행으로 종종 성공적으로 실행하지 못하는 그래픽 X 프로그램을 위해서라면 그다지 추천하지 않는다는 것을 알아두셨으면 합니다.

유용한 시험 도구

ebuild를 작성하고 관리하기 위해 도움을 줄 몇몇 유용한 도구들이 있습니다.

도구 패키지 설명
repoman sys-apps/portage 절차상 CVS 체크를 도와주는 개발자 전용 도구 입니다. 일반적인 수많은 QA를 수행하고, 포티지 트리를 깨뜨리지 않을 CVS에 추가된 파일을 확인합니다
ccache dev-util/ccache 미리 처리된 파일을 유지하는 도구이며, 재 컴파일을 매우 빠르게 처리합니다. ccache를 /etc/make.conf의 FEATURES 변수에 넣어주셔야 합니다
sandbox sys-apps/sandbox 샌드박스 환경을 만드는 쉘을 실행합니다. 포티지로 패키지 내용을 빌드하고 직접 디버깅하는 동일한 환경으로 진입하는데 유용합니다.
echangelog app-portage/gentoolkit-dev 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.
원본 주소 "https://wiki.gentoo-kr.org/index.php?title=Trans:EbuildHowTo&oldid=1027"