Trans:EbuildHowTo - 편집 역사

Gentookorea: /* 유용한 시험 도구 */

2013-03-20T08:31:00Z

유용한 시험 도구

Onionmixer: 카테고리 추가

2013-03-17T10:26:27Z

카테고리 추가

Darkcircle: /* 패키지 시험 */

2012-07-12T20:20:39Z

패키지 시험

Gentookorea: /* ebuild 파일 이름 짓기 */

2012-07-12T19:57:57Z

ebuild 파일 이름 짓기

Gentookorea: /* ebuild 파일 이름 짓기 */

2012-07-12T19:57:35Z

ebuild 파일 이름 짓기

Gentookorea: /* 테스트 및 배포 */

2012-07-12T19:56:13Z

테스트 및 배포

Gentookorea: /* 유용한 시험 도구 */

2012-07-12T19:56:02Z

유용한 시험 도구

Gentookorea: /* 패키지 시험 */

2012-07-12T19:55:49Z

패키지 시험

Gentookorea: /* 여러분의 ebuild를 따로 저장하기 */

2012-07-12T19:55:38Z

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

Gentookorea: /* ChangeLog */

2012-07-12T19:55:25Z

ChangeLog

← 이전 판		2013년 3월 20일 (수) 08:31 판
821번째 줄:		821번째 줄:


−	[[Category:~~GenooTrans~~]]	+	[[Category:GentooTrans]]

← 이전 판		2013년 3월 17일 (일) 10:26 판
819번째 줄:		819번째 줄:
	\| 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.		\| 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.
	\|}		\|}
		+
		+
		+	[[Category:GenooTrans]]

@@ 787번째 줄: / 787번째 줄: @@
 ==== 패키지 시험 ====
-이 패키지가 동작하는지 어떻게 테스트 할 것인지를 생각해보도록 합니다. 가끔 개발자는 패키지의 기본적인 기능성을 테스트 하기 위해 이미 들어간 '''make test'''나 '''make check'''루틴을 보유합니다. 만약 이렇다면 '''FEATURES=test ebuild foo-x.y.z.ebuild test'''를 >실행할 때 '''make test'''나 '''make check'''루틴을 실행할 것입니다. 이게 깨졌다면 이게 제대로 동작하도록 고쳐보려 할 것입니다 (그리고 업스트림 개발자에게 패치를 제공할 것입니다).
+이 패키지가 동작하는지 어떻게 테스트 할 것인지를 생각해보도록 합니다. 가끔 개발자는 패키지의 기본적인 기능성을 테스트 하기 위해 이미 들어간 '''make test'''나 '''make check'''루틴을 보유합니다. 만약 이렇다면 '''FEATURES=test ebuild foo-x.y.z.ebuild test'''를 실행할 때 '''make test'''나 '''make check'''루틴을 실행할 것입니다. 이게 깨졌다면 이게 제대로 동작하도록 고쳐보려 할 것입니다 (그리고 업스트림 개발자에게 패치를 제공할 것입니다).
 이 상황이 고려되지 않았다면 '''src_test''' 루틴을 ebuild에 넣는 것을 고려해보도록 합니다. '''src_install'''루틴을 수행하기 전에 이것을 먼저 실행할 것이고 여러 아키텍처에서 프로그램이 동작하는 것을 시험하는데 매우 도움이 될 수 있을 것입니다. 여기에 루틴을 추가

@@ 63번째 줄: / 63번째 줄: @@
 세번째 하위 섹션, '''{_suf{#}}'''는 다음의 미리 정의된 접미어들중 하나를 선택적으로 포함하며, 덜 최신인 것부터 가장 최신인 순으로 나열하였습니다.
 {| class="wikitable"
 ! scope="cols"| 접미어
@@ 83번째 줄: / 82번째 줄: @@
 | 패치 레벨(보통 정수가 딸려옴)
 |}
 이들 접미어들에는 linux-2.4.0_pre10과 같이 0이 아닌 양의 정수가 딸려옵니다. 동>일한 버전 부분을 감안하여, 접미어는 다음과 같은 순서로 나열됩니다 ( 낮다는 것은 오래됨을 의미합니다 ): '''_alpha''' < '''_beta''' < '''_pre''' < '''_rc''' < (접미어 없음)< '''_p'''.

@@ 63번째 줄: / 63번째 줄: @@
 세번째 하위 섹션, '''{_suf{#}}'''는 다음의 미리 정의된 접미어들중 하나를 선택적으로 포함하며, 덜 최신인 것부터 가장 최신인 순으로 나열하였습니다.
 {| class="wikitable"
 ! scope="cols"| 접미어
@@ 82번째 줄: / 83번째 줄: @@
 | 패치 레벨(보통 정수가 딸려옴)
 |}
 이들 접미어들에는 linux-2.4.0_pre10과 같이 0이 아닌 양의 정수가 딸려옵니다. 동>일한 버전 부분을 감안하여, 접미어는 다음과 같은 순서로 나열됩니다 ( 낮다는 것은 오래됨을 의미합니다 ): '''_alpha''' < '''_beta''' < '''_pre''' < '''_rc''' < (접미어 없음)< '''_p'''.

← 이전 판		2012년 7월 12일 (목) 19:56 판
819번째 줄:		819번째 줄:
	\| 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.		\| 새 ChangeLog를 만들거나, 이미 존재한다면 항목을 추가할 수 있습니다.
	\|}		\|}
−
−	~~=== 테스트 및 배포 ===~~
−	~~==== ChangeLog ====~~
−	ebuild를 새로 받을(혹은 새로 작성할) 때마다 이에 대한 ChangeLog를 새로 고쳐(혹은 새로 만들어)야 합니다. skel.ChangeLog에는 기반으로 사용할 수 있는 간단한 ChangeLog가 있습니다.

@@ 795번째 줄: / 795번째 줄: @@
 ==== 유용한 시험 도구 ====
- ebuild를 작성하고 관리하기 위해 도움을 줄 몇몇 유용한 도구들이 있습니다.
+ebuild를 작성하고 관리하기 위해 도움을 줄 몇몇 유용한 도구들이 있습니다.
 {| class="wikitable"

@@ 780번째 줄: / 780번째 줄: @@
 ==== 여러분의 ebuild를 따로 저장하기 ====
- ebuild를 테스트 할 수 있게 하고, 포티지가 이것을 알아채게끔 하려면, 기존의 알려진 디렉터리에 이것(ebuild)들을 넣어야 합니다. 포티지는 /etc/make.conf에 설정할 수 있는 PORTDIR_OVERLAY변수를 사용할 것입니다. 사용할 디렉토리를 이 변수에 (/usr/local/portage 처럼) 설정할 필요가 있습니다.
+ebuild를 테스트 할 수 있게 하고, 포티지가 이것을 알아채게끔 하려면, 기존의 알려진 디렉터리에 이것(ebuild)들을 넣어야 합니다. 포티지는 /etc/make.conf에 설정할 수 있는 PORTDIR_OVERLAY변수를 사용할 것입니다. 사용할 디렉토리를 이 변수에 (/usr/local/portage 처럼) 설정할 필요가 있습니다.
- 이 디렉토리에 /usr/portage와 같은 구조 (와 카테고리) 를 사용하여야 합니다.
+이 디렉토리에 /usr/portage와 같은 구조 (와 카테고리) 를 사용하여야 합니다.
 ==== 패키지 시험 ====
   이 패키지가 동작하는지 어떻게 테스트 할 것인지를 생각해보도록 합니다. 가끔 개발자는 패키지의 기본적인 기능성을 테스트 하기 위해 이미 들어간 '''make test'''나 '''make check'''루틴을 보유합니다. 만약 이렇다면 '''FEATURES=test ebuild foo-x.y.z.ebuild test'''를 >실행할 때 '''make test'''나 '''make check'''루틴을 실행할 것입니다. 이게 깨졌다면 이게 제대로 동작하도록 고쳐보려 할 것입니다 (그리고 업스트림 개발자에게 패치를 제공할 것입니다).

@@ 773번째 줄: / 773번째 줄: @@
 === 테스트 및 배포 ===
 ==== ChangeLog ====
- ebuild를 새로 받을(혹은 새로 작성할) 때마다 이에 대한 ChangeLog를 새로 고쳐(혹은 새로 만들어)야 합니다. skel.ChangeLog에는 기반으로 사용할 수 있는 간단한 ChangeLog가 있습니다.
+ebuild를 새로 받을(혹은 새로 작성할) 때마다 이에 대한 ChangeLog를 새로 고쳐(혹은 새로 만들어)야 합니다. skel.ChangeLog에는 기반으로 사용할 수 있는 간단한 ChangeLog가 있습니다.
- ChangeLog의 목적은 무엇을 했는지, 왜 했는지, 누가 했는지를 문서화 하는 것입니다. 이를 통해 개발자와 사용자가 변경사항을 쉽게 추적할 수 있습니다.
+ChangeLog의 목적은 무엇을 했는지, 왜 했는지, 누가 했는지를 문서화 하는 것입니다. 이를 통해 개발자와 사용자가 변경사항을 쉽게 추적할 수 있습니다.
 ==== 여러분의 ebuild를 따로 저장하기 ====
   ebuild를 테스트 할 수 있게 하고, 포티지가 이것을 알아채게끔 하려면, 기존의 알려진 디렉터리에 이것(ebuild)들을 넣어야 합니다. 포티지는 /etc/make.conf에 설정할 수 있는 PORTDIR_OVERLAY변수를 사용할 것입니다. 사용할 디렉토리를 이 변수에 (/usr/local/portage 처럼) 설정할 필요가 있습니다.