레드햇 패키징 하우투 RPM HOWTO (RPM at Idle): RPM 만들기

6. RPM 만들기

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

/etc/rpmrc가 있는지 확인한다.
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)

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

Summary: 패키지에 대한 간단한 설명을 한 줄로 쓴다.
Name: 여러분이 사용하고자 하는 rpm 파일 이름이 와야 한다.
Version: 여러분이 사용할 파일 이름의 버전 번호가 와야 한다.
Release: 여기에는 같은 버전의 패키지 번호가 온다. (예를 들어 우리가 패 키지를 만들었는데 잘못된 것을 알고 다시 만들었을 때 다음 패키지의 release 번호는 2가 된다.)
Icon: 여기에는 다른 (레드햇의 ``glint;;와 같은) 시각적인 설치 도구 에서 사용할 아이콘 파일의 이름이 온다. 아이콘은 반드시 gif 포맷이어야 하고 SOURCES 디렉토리에 위치하여야 한다.
Source: 이 줄에서는 원래 소스 파일의 위치를 가리킨다. 이것은 여러분이 소스 파일을 다시 얻거나 새로운 버전을 체크하는데 쓰인다. 주의: 이줄에서 파일 이름은 여러분의 시스템에 있는 파일 이름과 일치해야 한다. (예를 들어, 소스 파일을 다운로드 받아서 이름을 바꾸지 말아야 한다.) 여러분은 하나 이상의 소스 파일을 다음과 같은 라인을 사용하여 지정할 수 있다.
Source0: blah-0.tar.gz Source1: blah-1.tar.gz Source2: fooblah.tar.gz
이 파일들은 SOURCE 디렉토리에 위치한다(이 디렉토리 구조는 뒤의 "소스 디렉토리 트리" 단락에서 다룰 것이다.)
Patch: 패치를 찾을 수 있는 위치이다. 다시 다운로드 받을 때 필요하다. 주의: 여기서의 파일 이름은 "여러분의" 패치를 만들 때 사용하는 것과 일치하여야 한다. 여러 소스에서 여러 패치 파일을 가지고 있을 때 주목할 필요가 있다.
Patch0: blah-0.patch Patch1: blah-1.patch Patch2: fooblah.patch
이 파일들은 SOURCES 디렉토리 안에 있어야 한다.
Copyright: 이 줄에서는 패키지의 저작권을 알려준다. 여러분은 APL, BSD, MIT, 공개(public domain), distributable, 또는 상용 (commercial)과 같이 쓸 수 있다.
BuildRoot: 이 줄에서는 새로운 패키지를 설치하고 만드는 ``root'' 디렉토리를 지정하도록 한다. 여러분은 설치하기 전에 여러분의 패키지를 테스트하는데 이를 사용할 수 있다.

Group: 이 줄은 (레드햇 ``glint''와 같은) 시각적 설치 프로그램에서 특정한 프로그램이 트리 구조에서 어디에 위치하는지 알려준다. 그룹 트리는 현재 이러한 구조를 가지고 있다.


Applications
  Communications
  Editors
        Emacs
  Engineering
  Spreadsheets
  Databases
  Graphics
  Networking
  Mail
  Math
  News
  Publishing
        TeX
Base
  Kernel
Utilities
  Archiving
  Console
  File
  System
  Terminal
  Text
Daemons
Documentation
X11
  XFree86
        Servers
  Applications
        Graphics
        Networking
  Games
        Strategy
        Video
  Amusements
  Utilities
  Libraries
  Window Managers
Libraries
Networking
  Admin
  Daemons
  News
  Utilities
Development
  Debuggers
  Libraries
        Libc
  Languages
        Fortran
        Tcl
  Building
  Version Control
  Tools
Shells
Games

%description 이것은 헤더 아이템이 아니지만, 여기서 설명해 두어야 한다. 당신의 패키지, 서브 패키지마다 설명을 하나씩 필요로 할 것이다. 이것은 패키지에 대해서 참고적인 설명을 쓰는데 사용하는 것이고 여러 줄에 걸쳐 쓸 수 있다:

6.4 준비 (Prep)

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

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

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

-n name 에서는 리스트된 이름에 빌드할 디렉토리의 이름을 정하는데, 기본값은 $NAME-$VERSION이다. 다른 가능성이 있는 $NAME, ${NAME}${VERSION} 또는 사용하는 tar 파일이 올 수도 있다. (명세 파일 안에 있는 ``$'' 변수는 실제 변수가 아니라는 점에 주의하기 바란다. 그것은 실제로 샘플 이름이 위치할 곳을 나타내는데 쓰인다. 여러분은 변수가 아닌 패키지의 실제 이름과 버전을 사용할 필요가 있다.)
-c untar를 실행하기 전에 디렉토리를 만들고 그곳으로 이동하는 것이다.
-b # 는 그 디렉토리로 이동하기 전에 소스#의 압축을 풀 것이다.(untar) (-c와 함께 사용할 수는 없다.) 이것은 여러 개의 소스 파일이 있을 때만 유용하다
-a # 는 디렉토리로 이동한 후에 소스#의 압축을 풀 것이다.
-T 옵션은 압축을 푸는 기본 기능을 무시하고 압축 풀린 소스 파일을 얻기 위하여 -b 0 또는 -a 0 를 필요로 한다. 부차적인 소스가 있을 때 이 옵션이 필요하다.
-D -D 는 소스를 풀기 전에 디렉토리를 지우지 않는 옵션이다. 이것은 여러분 이 하나 이상의 셋업 매크로를 가지고 있을 때만 유용하다. 이것은 셋업 매크로 중 첫번째 것을 사용한 후에 쓰인다. (첫번째에 있으면 절대 안된다.)

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

# 는 패치 파일로 패치 # 를 적용한다.
-p #는 패치 명령(patch(1))을 strip할 디렉토리의 수를 지정한다.
-P 의 기본 기능은 패치를 적용하는 것이다. 이 플래그는 기본 기능이고 압축 풀린 메인 소스 파일을 얻기 위해서 0이 하나 필요하다. 이 옵션은 첫 번째 매크로와 다른 숫자를 필요로 하는 두번째 %patch 매크로에서 유용하다.
여러분은 역시 실제 명령을 내리는 대신 %patch# 를 쓸 수 있다: %patch # -P

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

6.5 빌드

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

6.6 설치

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

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

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

%pre 설치하기 전에 실행되는 스크립트이다.
%post 설치한 후에 실행되는 스크립트이다.
%preun 제거하기 전에 실행되는 스크립트이다.
%postun 제거한 후에 실행되는 스크립트이다.

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

6.8 파일

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

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

%doc 여러분이 바이너리로 설치하기를 원하는 소스 패키지 내의 문서를 표시하는데 사용된다. 문서는 /usr/doc/$NAME-$VERSION-$RELEASE에 설치될 것이다. 여러분은 매크로를 써서 명령행에서 여러 문서를 리스트하거나, 모두 각각 매크로를 써서 리스트할 수도 있다.
%config 는 패키지에서 설정 파일을 표시하는데 사용한다. 여기엔 sendmail.cf, passwd와 같은 파일을 포함한다. 여러분이 나중에 설정 파일을 담고 있는 패키지를 제거하고자 한다면, 수정하지 않은 파일은 모두 제거되고 수정된 파일은 .rpmsave 를 붙여 이름을 바꾸어 둔다. 여러분은 역시 이러한 매크로로 여러 개의 설정 파일을 리스트할 수 있다.
%dir 파일 안의 패키지에 포함되는 파일 리스트 안의 단일 디렉토리를 표시한다. 기본값으로, 여러분은 디렉토리 이름을 %dir 없이 나열할 수 있다, 디렉토리의 모든것은 파일 리스트 안에 포함되고 나중에 패키지의 한 부분으로 설치된다.
%files -f <filename> 로는 소스의 빌드 디렉토리 안에 있는 몇몇 임의의 파일에서 여러분의 파일을 리스트할 수 있다. 이는 여러분이 파일 리스트를 직접 빌드할 수 있는 패키지를 가지고 있는 경우에 좋다. 여러분은 여기 있는 파일 리스트만 포함시키고, 여러분은 특별히 파일을 리스트할 필요가 없다.

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

6.9 빌드하기

소스 디렉토리 트리

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

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

BUILD 는 RPM에 의해서 모든 빌드가 이루어지는 디렉토리이다. 여러분은 특정한 곳에서 빌드 테스트를 할 필요는 없지만, 이 디렉토리가 RPM이 빌드할 위치이다.
SOURCES 오리지널 소스 tar 파일과 패치를 넣어 두어야 하는 디렉토리이다. 이는 기본적으로 RPM이 참고하는 곳이다.
SPECS 은 명세 파일이 위치할 디렉토리이다.
RPMS 는 RPM이 바이너리 RPM을 빌드할 디렉토리이다.
SRPMS 모든 소스 패키지가 놓여질 곳이다.

빌드 테스트

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


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

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

파일 리스트 생성

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

RPM으로 패키지 만들기

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


rpm -ba foobar-1.0.spec

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

p 는 명세 파일의 prep 단락을 실행한다는 것을 의미한다.
l 은 리스트 체크이다.
c 는 prep를 하고 컴파일한다. 이것은 여러분이 어떠한 소스를 빌드해야 할지 정확하지 않을 때 유용하다. 소스를 빌드하고 RPM을 사용하기 시작할 때까지는 여러분이 소스만 가지고 작업할지도 모르기 때문에 쓸모 없게 보인다. 그렇지만 RPM을 사용하는데 익숙해지면, 여러분은 이것을 사용할 때. 실례로써 찾을 수 있을 것이다.
i 는 prep 컴파일, 설치를 한다.
b 는 prep 컴파일, 설치와 바이너리 패키지만 만든다.
a 는 소스와 바이너리 모두 만든다.

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

--short-circuit 은 특정한 단계를 바로 건너뛴다. (c와 i에서만 쓸 수 있다.)
--clean 은 작업이 끝나면 빌드 트리를 지운다.
--keep-temps /tmp에 만들어진 모든 임시 파일과 스크립트 을 그대로 둔다. 여러분은 -v> 옵션을 사용하여 실제로 tmp에 어떠한 파일이 만들어지는지 볼 수 있다.
--test 는 실제 어떠한 단계도 실행하지 않는다, 다만 임시로 보존한다.

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 등이 될 것이다.

다음 이전 차례