![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Part 1을 아직 읽지 않았다면 이 글을 시작하기 전에 반드시 읽기 바란다.
Part 1에서 보았듯이, RPM 패키지를 구현할 때에는 일반적으로 root로서 로그인을 해야 한다. 이유는 다음과 같다:
- RPM은 패키징 프로세스 동안 소프트웨어를 설치한다. 일반적으로 root 사용자만이 설치 디렉토리에 작성할 수 있다.
- RPM은 /usr/src/redhat의 디렉토리에서 읽기와 쓰기를 수행할 것을 기대한다. 일반 사용자들은 변경할 수 없다.
RPM 구현 root를 사용해서 Part 1의 첫번째 문제를 해결하는 방법을 보았다.
두 번째 문제를 해결하기 위해서, RPM에게 %_topdir 설정을 변경하여 다른 디렉토리에서 파일을
만들도록 명령할 수 있다. 다음과 같이 .rpmmacros 라는 홈 디렉토리에 파일을 만들어보자:
이것은 RPM 에게 이전에는 /usr/src/redhat 하에서 찾았던 모든 디렉토리가 /home/your_userid/rpm
하에 있어야 한다는 것을 말해준다. 이제 전체 디렉토리 트리를 만들어 보자:
~/rpm
~/rpm/SOURCES
~/rpm/SPECS
~/rpm/BUILD
~/rpm/RPMS
~/rpm/RPMS/i386
~/rpm/SRPMS
(원한다면, 모든 디렉토리는 원하는 곳에 둘 수 있다. RPM에서 다른 매크로를 재정의 하면 된다. 변경을 고려하고 있는 몇몇
매크로에는 %_sourcedir, %_specdir, %_srcrpmdir,
%_builddir, %_rpmdir 등이 포함된다. 디폴트 값을 볼 때에는 /usr/lib/rpm/macros를
본다.)
indent-2.2.6.tar.gz 파일을 (참고자료)
~/rpm/SOURCES 에 복사한다. 그리고 root로서 로그인 하지 않고, rpm -ba indent-2.spec
(이러한 파일들은 Part
1과 같다)을 실행시킨다. RPM은 ~/rpm/BUILD에 indent를 구현할 것이다. 그리고,
바이너리 RPM 패키지를 ~/rpm/RPMS/i386에 놓고 소스 패키지를 ~/rpm/SRPMS에 놓는다.
그와는 반대로, 구현 root 없이 스펙 파일인 indent-1.spec을 사용해 보자. RPM은 /usr/local/bin에서
indent 설치를 시도하는 동안 작동이 되지 않는다.
구현 root를 사용하고 RPM의 i%_topdir를 설정하면 root로서 실행할 필요가 없는 많은 소프트웨어
패키지를 구현할 수 있다. 하지만 항상 쉬운 것만은 아니다.
우선, 몇몇 패키지는 indent로서 구현 root로 설치하는 것이 쉽지 않다. GNU autoconf를
사용하여 개발되지 않은 패키지가 있다면 다른 디렉토리로 설치할 수 있는 방법이 있는지와 Makefile을 변경할 수 있는지를
살펴봐야 한다. 다음 섹션에서는 RPM을 사용하여 변경된 프로그램을 구현하는 방법을 설명하겠다.
두 번째, 어떤 패키지는 일반적인 설치 동안 오직 root만이 할 수 있는 작업 수행을 시도하게 될 것이다. 다음과 같다:
- 특별 파일 만들기(pipe, 디바이스 파일)
- 시스템 설정 파일 변경하기
포스트 인스톨(post-install) 스크립트 (RPM을 설치한 후 실행되는 스크립트)에서 여러분은 필요한 작업을 수행할 수 있다. 다음 편에 이 부분을 다루겠지만 간단히 "%post" 섹션을 스펙 파일에 추가하고 리눅스 명령어로 RPM이 설치 된 후 실행시켜보자.
RPM과 같은 패키지를 원하는 소프트가 있다면 몇 가지 변경없이는 리눅스에서는 구현할 수 없다. 소프트웨어를 갖고있지 않기 때문에 공식적인 변경을 할 수 없다.
여러분이 할 수 있는 일은 정식 버전의 소프트웨어를 패치하거나 변경하는 것이다. 하지만 다른 사람의 소프트웨어의 변경 버전을 배포하는 것는 일반적으로 무례한 행동으로 간주된다. 하지만 변경 역시 하고 싶을 것이다.
RPM이 몇 가지 도움을 줄 수 있다. RPM 패키지를 설치하여 바이너리 RPM 파일에는 변경된 버전의 프로그램을 포함시키고, 소스 RPM에는 원래 소스 뿐만아니라 변경된 것은 물론 그들이 적용되고 구현된 방법에 대한 세부설명까지 포함시킨다.
다음과 같은 단계를 따른다:
- 소프트웨어가 작동할 수 있도록 하기위해 어떤 소스코드를 변경할 것인가를 구상한다.
- 변경사항이 기록된 패치 파일을 만든다.
- 패치를 RPM 스펙파일에 추가한다.
Step 1. 어떤 소스 코드를 변경할 것인지를 구상한다
일반적으로 첫 번째로는 RPM없이 소프트웨어를 컴파일 및 실행시키는 것이다. 어떤 파일을 변경해야 하는지를 지속적으로 트래킹 한다. 필요하다면 새로운 파일을 만들거나 기존 소스가 있는 파일을 제거할 수 있다.
예를 들어, indent-2.2.6-working 디렉토리에 코드의 압축을 풀었다. 프로그램이 시작할 때 익숙한 메시지를 프린트하기 위해서 indent.c를 변경하고 그런다음 프로그램이 여전히 구현되고 작동하고 있다는 것을 확인했다.
변경사항만을 기록한 패치 파일을 만들어야 한다. 한 가지 방법이 있다. 약간 장황하지만 모든 변경 사항을 기록할 수 있다.
- 소프트웨어를 새로운 디렉토리에 압축을 푼 다음 변경한 파일 버전들을 복사한다. 이것은 전에 소프트웨어를 구현하고 테스트하는 동안 만들어졌을 수도 있는 디렉토리에 추가적인 파일들을 갖지 않도록 하기 위해서이다. 여러분이 만든 새로운 모든 파일들을 복사하고 전에 지웠던 모든 파일들을 지운다.
- 다른 디렉토리에 압축을 푼다. 이것은 여러분의 것과 다른 것을 비교하기 위해서 원본 소프트웨어의 복사본을 제공하는 것이다.
이제 세 개의 디렉토리가 있다:
- indent-2.2.6-working
- 실행 장소
- indent-2.2.6-my
- 변경사항이 추가된 소프트웨어
- indent-2.2.6
- 변경되지 않은 소프트웨어
- 이 세 개의 디렉토리의 부모 디렉토리로 부터 이와 같은 명령어로 패치 파일을 만든다:
diff -uNr indent-2.2.6 indent-2.2.6-my >indent-2.2.6.patch
diff 에 -uNr 옵션을 사용한다는 것을 주목하자. -u
는 일관된(unified) 형식으로 패치를 만든다. -N 은 패치 파일이 파일을 만들고 지우는
작업을 정확히 핸들할 수 있도록 한다. -r 은 명령어 라인상에 있는 두 개의 디렉토리의 모든 하위 디렉토리에
있는 모든 파일들을 비교한다.
디렉토리의 이름들은 문제가 되지 않는다는 것도 주목하자. 디렉토리 이름은 패치 파일에 나타나겠지만 그것들을 무시하도록 패치 프로그램에게 지시할 것이다.
이제 패치 파일 indent-2.2.6.patch를 살펴보자:
Listing 1. indent-2.2.6.patch
diff -uNr indent-2.2.6/indent.c indent-2.2.6-my/indent.c
--- indent-2.2.6/indent.c Thu Nov 16 22:01:04 2000
+++ indent-2.2.6-my/indent.c Wed Sep 26 14:33:11 2001
@@ -1864,6 +1864,8 @@
int using_stdin = false;
enum exit_values exit_status;
+ printf("Hello from Dan
");
+
#ifdef _WIN32
/* wildcard expansion of commandline arguments, see wildexp.c */
extern void wildexp (int *argc, char ***argv); |
가끔씩 diff 가 여러분이 의도하지 않던 변경 사항을 집어낸다는 것을 기억하라. 이럴 때에는 다시
뒤돌아 가서 코드를 정리하고 패치를 다시 만든다. 보기 좋은 깨끗한 패치 파일을 만들때 까지..
일단 원하던 대로 패치가 만들어 졌으면 여러분이 이룩한 것에 대해 설명 주석을 추가하는 것도 좋다. 패치 파일의 시작과 끝에 텍스트를 추가할 수 있다.
Listing 2. indent-2.2.6.patch -- 주석 추가
Dan Poirier - 2001-09-26 - added a friendly greeting as indent starts.
This is just an example.
diff -uNr indent-2.2.6/indent.c indent-2.2.6-my/indent.c
--- indent-2.2.6/indent.c Thu Nov 16 22:01:04 2000
+++ indent-2.2.6-my/indent.c Wed Sep 26 14:33:11 2001
@@ -1864,6 +1864,8 @@
int using_stdin = false;
enum exit_values exit_status;
+ printf("Hello from Dan
");
+
#ifdef _WIN32
/* wildcard expansion of commandline arguments, see wildexp.c */
extern void wildexp (int *argc, char ***argv); |
이제 RPM이 여러분의 패치를 사용할 수 있도록 해야 한다. 이것을 SOURCES 디렉토리에 복사하고 스펙 파일을 변경한다:
Listing 3. indent-3.spec: indent-2.2.6.patch 사용하기
Summary: GNU indent
Name: indent
Version: 2.2.6
Release: 3
Source0: %{name}-%{version}.tar.gz
Patch0: %{name}-2.2.6.patch
License: GPL
Group: Development/Tools
BuildRoot: %{_builddir}/%{name}-root
%description
The GNU indent program reformats C code to any of a variety of
formatting standards, or you can define your own.
%prep
%setup -q
%patch -p1
%build
./configure
make
%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
/usr/local/bin/indent
%doc /usr/local/info/indent.info
%doc %attr(0444,root,root) /usr/local/man/man1/indent.1
%doc COPYING AUTHORS README NEWS
|
rpm -ba indent-3.spec으로 패키지를 만들자. 구현되는 동안 RPM이 패치를 적용한다는
것을 알 수 있다.
%Patch0: %{name}-2.2.6.patch 라인은 RPM에게 첫 번째 패치 파일의 이름을 말해준다.
필요할 경우 %Patch1, %Patch2 등을 추가할 수 있다.
%prep 섹션의 %patch -p1 라인은 RPM 매크로로서 시스템의 빌드
디렉토리에서 인풋으로서 첫 번째 패치 파일을 가지고 패치 프로그램을 실행 시킬 것이다.
RPM 패키지가 어떻게 구현되는지에 대한 기초를 이해했다. 이제 예제를 통해 더 깊이 들어가 보자. 최상의 소스 중 하나는 Linux 배포판이다. 예를 들어, RedHat 에는 소스 RPM 패키지 CD가 함께 제공된다. 다음은 사용방법이다.
소스 RPM 패키지에 포함되어 있는 것:
- .spec file
- 1개 이상의 소스 파일
- 사용 된 모든 패치 파일들
소스 RPM 패키지를 바이너리 RPM 패키지와 비슷하게 설치할 수 있다. rpm -i filename.rpm을
사용한다. 설치한 다음, .spec 파일은 %_specdir 디렉토리에 위치하고 소스 파일과 패치 파일은 %_sourcedir
디렉토리에 놓이게 된다. 위에 설명된 .rpmmacros 파일을 만들었다면 그것은 ~/rpm/SPECS와 ~/rpm/SOURCES가
된다.
Red Hat이 배포하는 패키지용 .spec 파일들을 읽을 수 있다. rpm -ba foo.spec을
이용하여 구현을 시도하여 어떤 일이 일어나는 지 보고 새로운 것을 시도하기 위해 스펙 파일을 이용해 보자.
GNU indent 프로그램 용 Red Hat의 소스 RPM 패키지가 시작하기에 좋다.
바이너리 RPM 패키지는 이식성이 좋지 않다. 대부분의 경우 한 리눅스 배포판에 구현된 RPM은 다른 곳에서는 작동하지 않는다. 심지어 같은 배포판의 다른 버전에서도 작동하지 않는다!
기본 커널 버전, 라이브러리 버전, 디렉토리 구조의 차이 등이 그 이유가 될 수 있다.
가능한 한 많은 배포판들에 여러분의 소프트웨어를 구현하기 위해서, .spec 파일과 패치 파일을 이용할 수 있도록 해야 한다.
필요할 경우 소프트웨어를 직접 변경하는 것이 최상의 방법이다. 그래서 이것을 리눅스에 구현하도록 한다. 배포판에는 .spec 파일을 포함시킨다. .spec 파일이 소스와 함께 tarball (.tar.gz file)에 있다면 간단히 실행시킬 수 있다:
rpm -tb foo.tar.gz |
그리고 패키지용 바이너리 RPM을 구현할 수 있다-- tar 파일을 언패킹(unpack)할 필요가 없다!
소프트웨어에 .spec 파일을 포함시킬 수 없다면 소스 RPM 패키지를 배포한다. 사용자는 이것을 실행시킬 수 있다:
rpm --rebuild foo.src.rpm |
그리고 바이너리 RPM을 시스템에 구현한다.
- developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
-
RPM을
이용한 소프트웨어 패키지, Part 1 (한글).
- 파일 소스:
-
RPM 웹 사이트.
-
Maximum RPM : RPM 사용 관련
책.
-
RPM HOWTO.
- Eric S. Raymond의
Software Release Practice HOWTO document.
-
Linux Standard Base (LSB).
-
Free Software Foundation: GNU Indent용
소스 및 기타 유용한 소프트웨어 패키지 제공.
-
IBM
Developer Kit>Open
source resources: developerWorks.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그