이전페이지 다음페이지 차례

6. RPM 만들기

RPM을 만드는 것은 무척 쉽다, 특히 여러분이 만들고자 하는 패키지를 얻었을 때는 더욱 그렇다. RPM을 만드는 기본적인 절차는 다음과 같다.

보통, RPM은 바이너리와 소스 모두 만든다.

6.1 rpmrc 파일 (The rpmrc File)

RPM 설정 파일은 /etc/rpmrc 파일에서만 이루어진다. 예를 들면 다음과 같다: 

require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp

require_vendor에는 RPM이 vender 줄을 찾을 때 필요하다. 이 줄은 /etc/rpmrc 명세 파일의 헤더에서 나온다. 이 기능을 끄려면, 숫자를 0으로 바꾼다. 같은 방법은 require_distribution과 require_group에서도 적용이 가능하다.

다음 줄은 distribution 줄이다. 여러분은 여기 또는 명세 파일 헤더의 뒷부분에 정의할 수 있다. 특정한 배포본에서 만들 때, 이 줄이 맞는지 확인하는 것은 매우 좋은 생각이다. 이것이 필요한 것은 아니지만, vender 줄도 같은 방법으로 이루어진다. 그렇지만 무엇이든지 올 수 있다. (예: Joe's Software and Rock Music Emporium).

RPM은 역시 다양한 아키텍처에서 패키지를 만드는 기능을 지원하고 있다. rpmrc 파일에는 아키텍처에 종속적인 플래그가 필요한 것을 빌드할 때 ``optflags'' 변수를 설정할 수 있다. 다음 단락에서 이러한 변수를 어떻게 사용하는지 볼 수 있다.

위에 있는 매크로에 더해서, 여기에는 몇 가지 더 있다. 여러분은 이렇게 사용할 수 있다: 

rpm --showrc

태그가 어떻게 세팅되는지, 사용 가능한 플래그가 어떤 것이 있는지 알기 위해 서는 위와 같은 명령을 내린다.

6.2 명세 파일 (The Spec File)

우리는 명세 파일에 대해 논의할 것이다. 명세 파일은 패키지를 만드는데 필요하다. 명세 파일에는 소프트웨어와 설치할 모든 바이너리와 그 파일 리스트를 어떻게 만드는지에 대하여 지시한 설명이데, 이는 소프트웨어에 따라오는 것이다.

여러분은 명세 파일을 표준 관례에 따라 이름짓기를 원할 것이다. 명세 파일 이름은 이름-버전번호-발표 번호.spec이 된다.

여기에 간단한 명세 파일이 있다. (vim-3.0-1.spec):

Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1

6.3 헤더 (The Header)

헤더에는 여러분이 채워넣을 필요가 있는 표준적인 필드를 담고 있다. 여기에는 몇 가지 주의할 것이 있다. 필드에는 반드시 다음과 같이 채워야 한다:

6.4 준비 (Prep)

이것은 명세 파일의 두번째 단락이다. 이것은 소스를 빌드할 준비를 하는데 쓰인다. 여기에서는 여러분이 소스 패치,make를 실행과 같은 셋업하는데 필요한 것들을 할 수 있다.

한가지 주의할 점: 각각 단락에는 실행할 쉘 스크립트가 위치하여야 한다. 여러분은 간단히 소스를 풀고 패치할 쉘스크립트를 만들어 %prep 뒤에 위치 시킬 수있다. 여기에서 우리는 도움이 되도록 매크로를 만들어 두었다.

매크로의 첫 번째는 %setup 매크로이다. 이것은 간단한 양식으로써 (명령행 옵션은 없다), 소스를 풀고 소스 디렉토리로 들어가는 것이다. 여기에는 다음과 같은 옵션이 있다:

사용 가능한 매크로중 다음으로는 %patch 매크로이다. 이 매크로는 소스에 패치를 가하는 과정을 자동화 하는 것을 돕는다. 여기에는 몇 가지 옵션이 있다. 다음과 같다:

%build 매크로에서 여러분이 포함하고자 하는 모든 것(다음 단락에서 논의할 것 이다.)은 쉘을 통하여 실행하는 것이다. 여기서 여러분이 원하는 모든 형태의 매크로에 대해서는 예제를 보라.

6.5 빌드

이 단락에서는 실제로 어떤 매크로가 있는 것은 아니다. 여러분은 압축 풀린 소스를 가지고 있을 때 사용하기 원하는 소프트웨어를 빌드하고, 그것을 패치하고 그 디렉토리로 이동하는 등의 어떠한 명령이든지 여기에 넣어야 한다. 이것은 명령들의 쉘에 전달되는 또다른 셋으로써, 어떠한 쉘 명령이든지 (설명을 포함해서) 여기에 쓸 수 있다. 여러분의 현재 작업 디렉토리는 각각의 단락마다 소스 디렉토리의 최상위 레벨 디렉토리로 리셋되므로, 따라서 이것을 기억하기 바란다. 여러분은 필요하다면 서브 디렉토리로 이동할 수 있다.

6.6 설치

이것 역시 실제 어떠한 매크로가 아니다. 여러분은 기본적으로 설치하는데 필요한 어떠한 명령이든지 여기에 넣기를 원할 것이다. 여러분이 빌드하는 패키지 안에서 make install을 사용할 수 있다면, 여기에 넣어 두도록 한다. 아니면, 여러분은 make install에 쓰일 makefile을 패치하거나 make install을 여기서 할 수 있다, 또는 수동적인 쉘 명령으로 설치할 수도 있다. 여러분은 현재 디렉토리가 소스 디렉토리의 가장 상위 디렉토리가 된다는 것을 생각하여야 한다.

6.7 설치와 제거의 선행/후행 스크립트

여러분은 바이너리 패키지의 설치나 제거 전후에 스크립트를 넣을 수 있다. 주된 이유는 공유 라이브러리를 담고 있는 패키지를 설치하거나 제거하고 나서 ldconfig와 같은 명령을 실행하기 위해서이다. 각각의 스크립트에 대한 이 매크로들은 다음과 같다:

이 단락의 내용은 #!/bin/sh 를 필요로 하지 않더라도 어떠한 쉘 스타일의 스크립트가 될 수 있다.

6.8 파일

여기는 여러분이 반드시 파일을 반드시 리스트해야 하는 단락이다. RPM은 make install의 결과로 어떠한 바이너리가 설치되는지 알 방법이 없다. 이것을 할 수 있는 방법은 "없다". 어떤 이는 패키지를 설치 전후에 find를 실행하기를 제의하기도 하였다. 다중 사용자 시스템에서는, 패키지 빌드가 이루어지는 동안 패키지 자체와는 아무런 관련이 없는 다른 파일이 생성될 수 있기 때문에 받아들이기 어렵다.

여기에는 특별한 작업에 사용 가능한 몇 가지 매크로가 있다. 여기에서 설명한다:

파일 리스트에서 가장 주의해야 할 것은 디렉토리 리스트이다. 여러분이 실수로 /usr/bin을 써 두었다면, 여러분의 바이너리 패키지는 여러분 시스템의 /usr/bin 안의 모든 파일을 담게 될 것이다.

6.9 빌드하기

소스 디렉토리 트리

여러분에게 가장 필요한 것은 적절히 맞추어진 빌드 트리이다. 이것은 /etc/rpmrc 파일에서 설정 가능하다. 대부분의 사람들은 /usr/src 를 사용할 것이다.

여러분은 빌드 트리를 만들기 위해 다음과 같은 디렉토리를 생성할 필요가 있다:

빌드 테스트

아마도 여러분이 가장 원하는 것은 RPM 없이 깨끗하게 컴파일되는 소스를 구하는 것이다. 이를 위해서는, 소스를 풀고 $NAME.orig 디렉토리로 이동한다. 그리고 소스를 다시 푼다. 빌드에서 이 소스를 사용하도록 한다. 소스 디렉토리로 이동하고 빌드하기 위해서 명령을 따른다. 여러분이 편집해야 할 것이 있다면, 패치를 필요로 할 것이다. 빌드하고 나면, 소스 디렉토리를 지운다. 설정 스크립트에서 만들어진 모든 파일들이 지워지는지 확인한다. 그 다음 다시 소스 디렉토리로 이동한다. 그 다음 여러분은 다음과 같은 명령을 내린다: 

        diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

이는 여러분이 명세 파일에서 사용할 수 있는 패치를 만드는 것이다. 여러분이 패치 파일 안에서 보는 ``linux''는 동일한지 확인하기 위한 것(identifier)에 불과하다는 것에 주목한다. 여러분은 ``config'', ``bugs''와 같은 패치를 만들어야만 하는 이유를 다룬 좀 더 자세한 설명과 같은 것을 원할는지 모르겠다. 바이너리가 실수로 포함되지 않는지 확인하기 위해서 사용하기 전에 패치 파일을 들여다 보는 것 역시 좋은 생각이다.

파일 리스트 생성

이제 여러분은 빌드할 소스를 가지고 있다. 그리고 빌드하고 설치하는 방법을 알고있다. 설치 과정의 출력을 보고 명세 파일 안에서 사용할 파일 리스트를 만든다. 우리는 일반적으로 명세 파일을 이러한 과정으로 동시에 만든다. 여러분은 초기화된 것을 만들고 쉬운 부분을 채울 수 있다. 그리고, 진행할 때 다른 곳을 채워 나간다.

RPM으로 패키지 만들기

여러분이 명세 파일을 갖게 되면, 여러분은 패키지를 빌드할 준비가 된 것이다. 가장 쓸만한 방법으로는 명령행에서 다음과 같은 명령을 내리는 것이다: 

rpm -ba foobar-1.0.spec

여기에는 유용한 -b 스위치와 함께 다른 옵션이 있다.

-b 스위치에는 몇 가지 수정 옵션이 있다. 다음과 같다:

6.10 테스트

여러분이 소스와 바이너리의 rpm 패키지를 가지고 있으면, 시험해 볼 필요가 있다. 가장 좋은 방법은 여러분이 빌드한 것을 다른 머신에서 사용해 보는 것이다. 결국, 여러분은 make install을 여러분의 머신에서 여러번 해볼 것인데, 그것은 반드시 잘 설치되어 있어야 한다.

여러분은 패키지를 시험하기 위해 rpm -u [패키지 이름] 를 실행할 수 있다. 그러나 여러분은 패키지를 빌드할 때, make install을 하였기 때문에 속을 수 있다. 파일 리스트에서 어떤 파일을 빠뜨렸다면, 그것은 제거되지 않을 것이다. 여러분은 바이너리 패키지를 다시 설치하면 여러분의 시스템은 다시 완전해질 것이지만, rpm은 그렇지 않다. rpm -ba [패키지 이름] 을 실행시켰기 때문에, 대부분의 사람들은 rpm -i [패키지]로 설치한다는 것을 확인하고 명심하라. 바이너리가 홀로 설치될 때 여러분이 빌드하거나 설치할 때 수행되어야 할 필요가 있는 것중 하지 않은 일이 있는지 확인하라.

6.11 새로운 RPM 패키지들로 할 수 있는 것

어떤 RPM 패키지를 만들고 나면 (아직 RPM으로 만들어지지 않은 것으로 가정한다.) 여러분은 여러분이 작업한 것을 다른 사람들이 사용할 수 있도록 기여 할 수 있다. (역시 RPM으로 만든 것이 자유롭게 배포될 수 있다는 것을 가정한다.) 그렇게 하려면, 여러분은 ftp.redhat.com에 업로드 할 수 있다.

6.12 지금은 무엇을?

테스트, 새로운 RPM 패키지들로 할 수 있는것" 단락을 보기 바란다. 우리는 구할 수 있는 모든 RPM을 사용할 수 있고, 우리는 그들에게 RPM이 도움이 되기를 원한다. 시험할 시간을 충분히 갖기를 바라고, 모든 이들이 그러한 혜택을 누릴 수 있도록 업로드하기를 바란다. 또한 여러분이 자유롭게 배포 가능한 소프트웨어만을 업로드 하기를 확인하기 바란다. 상용 소프트웨어와 쉐어웨어는 저작권에서 허가하지 않는한 업로드되어서는 안될 것이다. 이를 포함하고 있는 것은 Netscape software, ssh, pgp 등이 될 것이다.

이전페이지 다음페이지 차례