[패키지] 나도 이제 RPM을 만든다.

나도 이제 RPM을 만든다.

작성자 : 강기봉 (freekgb at netian.com, freekgb at hanmail.net)

작성일 : 1999.10.2.

이 파일은 낙엽 박상완 형님의 세미나 이후 HLUG 세미나용으로 만든 것입니다.

나름대로 세미나의 내용을 적용하였고, HOW-TO 문서를 참고하였습니다.

여러분께 도움이 되길 바라겠습니다.

1. RPM 설치하기

1] RPM 파일을 다운로드 받습니다.

ftp.redhat.com

미러사이트 : ftp.bora.net

2] RPM 시스템 요구사항

RPM을 사용하기 위해 주된 요구 사항은 cpio 버전 2.4.2 이상이 필요합니다.

RPM은 물론 리눅스에서 사용하고자 만들어졌지만, 다른 유닉스 시스템에도

포팅할 수 있을 것입니다. 사실은 SunOS, Solaris, AIX, Irix, AmigaOS,

그 외 여러 유닉스 에서 모두 컴파일됩니다. 다만 주의할 것이 있다면, 서로

다른 유닉스 시스템에서 만들어진 바이너리 패키지는 호환되지 않는다는

것입니다.

RPM을 설치하기 위한 최소 요구 사항은 다음과 같습니다. RPM을 소스에서 빌드

하기 위해서 , 여러분은 패키지를 컴파일하는데 필요한 것들, 즉, gcc, make

등이 필요합니다.

3] RPM 사용

1) RPM 은 패키지를 설치할 때 다음과 같이 사용할 수 있습니다.

a. 설치만

rpm -i foobar-1.0-1.i386.rpm

b. 정보와 함께

rpm -ivh foobar-1.0-1.i386.rpm

2) 다음은 패키지를 업그레이드 할 때 쓰이는 명령어입니다.

a. 설치만

rpm -U foobar-1.0-1.i386.rpm

b. 정보와 함께

rpm -Uvh foobar-1.0-1.i386.rpm

3) 다음의 간단한 명령은 패키지를 제거할 때 쓰는 것입니다.

rpm -e foobar

4) 매우 쓸모 있지만 더욱 복잡한 명령중 하나는 여러분이 FTP를 통하여

설치하는 것입니다. 여러분이 네트웍에 연결되어 있고 새로운 패키지를

설치하기를 원한다면, 여러분에게 필요한 것은 파일의 정확한 URL과

함께 파일의 위치를 정하는 것인데, 다음과 같습니다:

rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm

이제는 FTP 를 통한 설치와 질의 기능을 사용할 수 있습니다.

(&nbspftp/bin 디렉토리에 rpm 바이너리를 가져다 놓기 바랍니다. 그렇게

한다면 당신의 ftp 서버는 rpm 질의를 받을 수 있습니다.)

5) 질의하기

다음을 통하여 RPM 파일에 대한 것들을 알 수 있습니다.(질의 옵션)

rpm -Va              – 설치되어 있는 rpm 정보

rpm -qf /bin/vi      – 이미 설치되어 있는 rpm의 버젼 정보

rpm -qRp foobar-1.0-1.i386.rpm   – 해당 파일과 의존성을 갖는 파일들 출력

rpm -qip foobar-1.0-1.i386.rpm   – 해당 파일에 대한 파일 목록 표시

spec파일에 쓰인 정보 출력

rpm -qpl koules-1.2-2.i386.rpm   -설치할 파일의 목록 표시

6) RPM의 옵션(–help 설명)

아래의 옵션들을 용도에 맞게 조합하여 쓰면 위의 예들과 같은 결과를 얻을

수 있습니다.

–help                  – 지금 보고 있는 이 메시지를 출력한다

–version               – 사용 중인 rpm의 버전을 출력한다

모든 모드는 다음 인수를 지원한다:

–rcfile <file>      – /etc/rpmrc 와 $HOME/.rpmrc 대신 <file>을 사용한다

-v                    – 좀 더 자세히 출력한다

-vv                   – 정말로 자세히 출력한다 (디버깅 목적을 위해)

-q                      – 질의 모드

–root <dir>         – <dir>을 상위 레벨 디렉토리로 사용한다

–dbpath <dir>       – <dir>을 데이터베이스 디렉토리로 사용한다

–queryformat <qfmt> – 헤더 형식으로 <qfmt>를 사용한다 (-i 내포)

설치, 업그레이드, 질의 (-p 추가)에서 ftp URL을 파일 이름 대신 적을 수 있으며

기타 다음 옵션을 사용할 수 있다:

–ftpproxy <host>    – ftp 프록시의 호스트 이름 또는 IP

–ftpport <port>     – ftp 서버(또는 프록시)의 포트 번호

–httpproxy <host>    – http 프록시의 호스트 이름 또는 IP

–httpport <port>     – http 서버(또는 프록시)의 포트 번호

패키지 명시 옵션:

-a                 – 모든 패키지를 질의한다

-f <file>+         – <file>을 소유하고 있는 패키지를 질의한다

-p <packagefile>+  – (아직 설치되지 않은) <packagefile> 패키지를

질의한다

–triggeredby <pkg> – <pkg>에 의해 유발되는 패키지를 질의한다

–whatprovides <cap> – <cap> 기능을 제공하는 패키지를 질의한다

–whatrequires <cap> – <cap> 기능을 필요로 하는 패키지를 질의한다

정보 선택 옵션:

-i                 – 패키지 정보를 표시한다

–changelog        – 패키지의 변화 기록을 표시한다

-l                 – 패키지 파일 목록을 표시한다

-s                 – 파일 상태를 보여준다 (-l 내포)

-d                 – 문서 파일만 나열한다 (-l 내포)

-c                 – 설정 파일만 나열한다 (-l 내포)

–dump             – 각 파일에 대하여 검증 가능한 정보를 보여준다 (-l,

-c, 또는-d와 함께 사용해야 한다)

–provides         – 패키지가 제공하는 기능을 나열한다

–requires

-R                 – 패키지 의존성을 나열한다

–scripts          – 다양한 [언]인스톨 스크립트를 출력한다

–triggers         – 패키지 안에 들어있는 유발 스크립트를 보여준다

-V

-y

–pipe <cmd>           – 표준 출력을 <cmd>로 보낸다

–verify               – -q와 같은 패키지 명시 옵션을 사용하여 패키지

설치를 검증한다

–dbpath <dir>       – <dir>을 데이터베이스 디렉토리로 사용한다

–root <dir>         – <dir>을 상위 레벨 디렉토리로 사용한다

–nodeps             – 패키지 의존성을 검증하지 않는다

–nomd5              – md5 체크섬을 검증하지 않는다

–nofiles            – 파일 속성을 검증하지 않는다

–setperms             – -q와 같은 패키지 명시 옵션을 사용하여 패키지

데이터베이스에 들어있는 파일의 허가권대로 설정한다

–setugids             – -q와 같은 패키지 명시 옵션을 사용하여 패키지

데이터베이스에 들어있는 파일 소유자와 그룹으로

설정한다

–install <packagefile>

-i <packagefile>       – 패키지를 설치한다

–excludepath <path> – <path> 경로에 있는 파일을 건너뛴다

–relocate <oldpath>=<newpath> – <oldpath>로부터 <newpath>로 파일을

재배치한다

–badreloc – 패키지에서 허용하지 않아도 파일을 재배치한다

–prefix <dir>       – 재배치 가능하면 <dir>로 패키지를 재배치한다

–dbpath <dir>       – <dir>을 데이터베이스 디렉토리로 사용한다

–excludedocs        – 문서를 설치하지 않는다

–force              – –replacepkgs –replacefiles에 대한 축약형

-h

–hash               – 패키지를 설치할 때 해쉬 표식을 출력한다 (-v와

사용하면 좋다)

–allfiles           – 다른 경우 설치하지 않을 수 있는 설정 파일

포함하여 모든 파일을 설치한다

–ignorearch         – 패키지 아키텍쳐는 검증하지 않는다

–ignoresize         – 설치 전에 디스크 공간 검사를 하지 않는다

–ignoreos           – 패키지 운영체제를 검증하지 않는다

–includedocs        – 문서를 설치한다

–justdb             – 데이터베이스는 갱신하되 파일 시스템은 변경하지

않는다

–nodeps             – 패키지 의존성을 검증하지 않는다

–noorder            – 의존성을 충족시키기 위한 패키지 설치 순서

재조정을 하지 않는다

–noscripts          – 설치 스크립트를 실행하지 않는다

–notriggers         – 패키지에 의해 유발되는 스크립트를 실행하지 않는다

–percent            – 패키지를 설치할 때 퍼센트를 출력한다

–replacefiles       – 패키지가 설치된 파일을 교체하더라도 설치한다

–replacepkgs        – 패키지가 이미 설치되어 있어도 다시 설치한다

–root <dir>         – <dir>을 상위 레벨 디렉토리로 사용한다

–test               – 설치하지는 않고 성공 실패 여부만 통보한다

–upgrade <packagefile>

-U <packagefile>       – 패키지 업그레이드 (–install과 같은 옵션에 몇

가지 더)

–oldpackage         – 더 예전 버전의 패키지로 업그레이드한다.

(–force를 사용하면 자동으로 선택된다

–erase <package>

-e <package>           – 패키지를 지운다(언인스톨한다)

–allmatches         – <package>와 일치하는 모든 패키지를 제거한다.

(보통은 <package>가 여러 개의 패키지와 일치하면

에러가 발생한다)

–dbpath <dir>       – <dir>을 데이터베이스 디렉토리로 사용한다

–justdb             – 데이터베이스는 갱신하되 파일 시스템은 변경하지

않는다

–nodeps             – 패키지 의존성을 검증하지 않는다

–noorder            – 의존성을 충족시키기 위한 패키지 설치 순서

재조정을 하지 않는다

–noscripts          – 패키지 고유의 스크립트를 하나도 실행하지 않는다

–notriggers         – 패키지에 의해 유발되는 스크립트를 실행하지 않는다

–root <dir>         – <dir>을 상위 레벨 디렉토리로 사용한다

-b<stage> <spec>

-t<stage> <tarball>    – 패키지를 제작한다. <stage>는 다음과 같다:

p                – 준비한다. (소스를 풀고 패치를 적용한다)

l                – 파일 목록 점검 (%files에 대하여 자세한 점검을

행한다)

c                – 컴파일한다. (준비 과정과 컴파일)

i                – 설치한다. (준비, 컴파일, 설치)

b                – 바이너리 패키지 (준비, 컴파일, 설치, 패키지)

a                – 바이너리/소스 패키지 (준비, 컴파일, 설치, 패키지)

–short-circuit      – skip straight to specified stage (only for c,i)

–clean              – remove build tree when done

–rmsource           – 작업을 마치고 나서 소스와 spec 파일을 지운다

–sign               – PGP/GPG 서명을 발생시킨다

–buildroot <dir>    – 제작 루트로 <dir>을 사용한다

–target=<platform>+ – 목표 플랫폼1…플랫폼N에 대한 패키지를 제작한다

–nobuild            – 어떠한 단계도 실행하지 않는다

–timecheck <secs>   – 시간 점검을 <secs> 초로 설정한다. (0은 해제)

–rebuild <src_pkg>    – 소스 패키지를 설치하고 바이너리 패키지를 만든 후

spec 파일과 소스, 패치, 아이콘을 삭제한다

–rmsource <spec>      – 소스와 spec 파일을 삭제한다

–recompile <src_pkg>  – –rebuild와 같지만 패키지는 만들지 않는다

–resign <pkg>+        – 패키지에 사인한다. (기존의 서명은 버린다)

–addsign <pkg>+       – 패키지에 서명을 추가한다

–checksig <pkg>+      – 패키지의 서명을 검증한다

–nopgp              – PGP 서명을 건너뛴다

–nogpg              – GPG 서명을 건너뛴다

–nomd5              – MD5 서명을 건너뛴다

–querytags            – 질의 형식에서 사용할 수 있는 태그를 나열한다

–initdb               – 올바른 데이터베이스가 있는지 확인한다

–rebuilddb            – 기존의 데이터베이스로부터 데이터베이스를 다시

만든다

–dbpath <dir>       – <dir>을 데이터베이스 디렉토리로 사용한다

–root <dir>         – <dir>을 상위 레벨 디렉토리로 사용한다

2. RPM 파일의 구분과 만들 때의 기본적 개념

1] SRPM과 RPM의 구분

rpm -ba foobar-1.0-1.i386.rpm

를 하여 RPM을 실행을 시키면 SRPM과 RPM이 만들어 집니다.

우리는 흔히 전자를 소스파일 후자를 바이너리 파일이라 합니다.

그것은 전자가 foobar-1.0-1.tar.gz과 foobar-1.0-1.spec 파일 및

이에 관한 patch 파일 등 rpm을 만드는 데 있어 재료가 된 파일들을

함께 묶어 놓고, 후자가 위 명령으로 만들어진 RPM 실행 파일이기 때문입니다.

2] sepc의 용도

위와 같이 RPM 명령을 내리면 이 파일을 읽어들여서 프로세스를 하게 됩니다.

이것은 조금은 특별한 스크립트 파일이며, %Prep 이후로 부터 스크립트 명령이

시작됩니다. 그러므로 주의할 점은 이 파일에 다른 명령어가 들어 있지 않은지

항상 확인하라는 것입니다. 만약 ‘rm -rf’ 등과 같은 명령어가 들어가 있다면

시스템을 다시 설치해야 하는 일도 생기게 될 수 있습니다. 앞 부분은 만들어진

파일들에 대한 정보가 들어갑니다.      

spec 파일은 SRPM에서 얻을 수 있으며, foobar-1.1-1.tar.gz과 같은 파일만

있을 때에는 직접 편집하여 사용하면 됩니다.  

3] RPM의 원리

RPM은 같은 종류의 시스템에서 패치한 패치한 부분까지를 포함한 소스를 그대로

사용하게 하는 것입니다. 말하자면 시스템에 이미 최적화되어 컴파일된 소스들을

묶어서 같은 종류의 다른 시스템에서 그대로 풀어서 사용할 수 있게 하는 것이죠.

따라서, spec 파일에는 원래 소스인 foobar-1.1-1.tar.gz 파일을 푸는 과정과

그것에서 makefile을 실행하여 컴파일하는 과정이 들어가 있으며, 이 컴파일된

파일들을 한데 모으는 과정을 거치게 됩니다. 또한 그렇기 때문에 다른 종류의

시스템에서는 만들어진 rpm 파일이 실행되지 않습니다.

3. RPM 만들기

RPM을 만드는 기본적인 절차는 다음과 같습니다.

가. /etc/rpm/rpmrc(또는 /usr/lib/rpm/rpmrc)가 있는지 확인한다.

나. RPM을 만들고자 하는 소스 코드를 구한다.

다. 정확하게 빌드하기 위해서 소스에 필요한 패치를 가한다.

라. 패키지에 대한 명세(spec) 파일을 만든다.

마. 모든 것이 정확한 위치에 있는지 확인한다.

바. RPM을 사용하여 패키지를 만든다.

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

1] RPM 위한 디렉토리

여러분에게 가장 필요한 것은 적절히 맞추어진 빌드 트리입니다. 이것은

/usr/lib/rpm/rpmrc 파일에서 설정 가능합니다. 대부분의 사람들은

/usr/src 를 사용할 것입니다. 레드햇 배포판에는 기본적으로

/usr/src/redhat를 사용합니다.

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

있습니다. 물론 레드햇에는 기본적으로 만들어져 있습니다:

가. BUILD – RPM에 의해서 모든 빌드가 이루어지는 디렉토리이다. 여러분은

특정한 곳에서 빌드 테스트를 할 필요는 없지만, 이 디렉토리가 RPM이

빌드할 위치이다.

나. SOURCES -오리지널 소스 tar 파일과 패치를 넣어 두어야 하는

디렉토리이다. 이는 기본적으로 RPM이 참고하는 곳이다.

다. SPECS – 명세(spec) 파일이 위치할 디렉토리이다.

라. RPMS – RPM이 바이너리 RPM을 빌드할 디렉토리이다.

마. SRPMS – 모든 소스 패키지가 놓여질 곳이다.

2]RPM 을 만들기 위한 방법 두가지(spec 파일에 관하여)

RPM을 만들기 위해서는 기본적으로 foobar-1.1-1.tar.gz 와 같은 프로그램

소스와 foobar-1.1-1.spec 와 같은 spec파일이 필요합니다. 전술한 바와 같이

RPM은 spec파일을 읽어서 소스를 풀고 컴파일하는 과정이 있기 때문입니다.

따라서, 두가지 파일이 필요한데, 이것들은 SRPM파일을 구해서 RPM 명령으로

풀면, 그것이 /usr/src/redhat 아래의 SOURCE와 SPECS 디렉토리 아래 풀리면서

그 두개의 파일이 생기게 됩니다. 그리고, 위와 같은 소스파일만 있다면 직접

spec 파일을 편집하여 사용하면 됩니다. 물론 이 경우에 직접 파일들을 언급한

디렉토리에 넣어 주어야 합니다.

SRPM 파일 구할 수 있는 사이트 : ftp.bora.net

3] 소스의 패치 파일 만들기

소스의 패치에는 diff 명령을 사용합니다.

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

위에서 .orig 가 붙은 것이 원래 파일 내지는 원래 디렉토리이고 것이 새로만든

것입니다. 이것을 비교하여 > 뒤에 있는 이름으로 patch파일이 만들어지게

됩니다. 이것은 spec 파일에서 적용이 되게 됩니다.

이것을 위해서 소스를 볼 수가 있어야 합니다. 그것을 위해서 다음과 같은 방법이

있습니다.

1) 소스를 직접 풀어서 패치할 곳을 찾아 패치합니다.

2) spec 파일을 편집한 후 다음과 같이 RPM 명령을 내려 소스를 빌드하는 것

까지만 하면 소스를 보고 패치파일을 만들 수가 있습니다. 물론 그 이후 다시

spec 파일을 편집하고, rpm명령을 통해 완전한 RPM파일을 만들면 됩니다.

rpm -bc foobar-1.0.spec

[주의] 이 파일은 SPECS 디렉토리 아래 있으며 그곳에서 실행합니다.

4] rpmrc 파일 (The rpmrc File)

RPM은 spec을 읽어들일 때 rpmrc 파일과 macro 파일을 참조하여 rpm 명령을

실행합니다. 이 파일들은 기본적으로 RPM이 설치되어 있는 디랙토리 아래에

위치합니다.

다음은 97년도 RPM문서를 가져온 것입니다. 기분 나쁜 단어는 바꾸었습니다.

조금 오래된 것이기 때문에 다른 부분이 조금 있습니다.

이 부분에서 잘못된 부분이 있다면 지적하여 주시거나 찾게 되면 수정하도록

하겟습니다.

RPM 설정 파일은 /usr/lib/rpm/rpmrc(또는 /etc/rpm/rpmrc) 파일에서만

이루어집니다. 예를 들면 다음과 같습니다:

require_vendor: 1

distribution: I roll my own!

require_distribution: 1

topdir: /usr/src/me

vendor: linux

packager: linux Packaging Account <packages at

linux.com>

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

optflags: alpha -O2

optflags: sparc -O2

signature: GPL

gpl_name: linux Packaging Account

gpl_path: /home/packages/.gpl

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

태그가 어떻게 세팅되는지, 사용 가능한 플래그가 어떤 것이 있는지 알기

위해서는 위와 같은 명령을 내립니다.

5] spec 파일 편집하기

전에 언급했듯이 RPM을 만들기 위해서는 spec 파일이 필요합니다. 그것을

읽어들여 RPM파일을 만들게 됩니다. 그러므로 그 파일을 직접 편집하거나

적어도 읽고 수정할 줄 알아야 합니다.

spec파일은 표준 관례에 따릅니다. spec 파일 이름은 이름-버전번호-발표

번호.spec이 되는 것입니다.

1) 파일의 첫 부분 – 헤더 (The Header)

파일의 처음 부분은 파일에 대한 전반적인 설명을 붙이게 됩니다.

다음은 ncftp의 spec파일 예입니다.

Summary: An improved FTP client.

Name: ncftp

Version: 3.0beta18

Release: 3

Prefix: /usr

Copyright: Distributable

Group: Applications/Internet

Source0: ftp://ftp.ncftp.com/ncftp/3.0BETA/ncftp-%{version}-src.tar.gz

Source1: ncftp.wmconfig

BuildRoot: /var/tmp/ncftp-root

%description

Ncftp is an improved FTP client.  Ncftp’s improvements include support

for command line editing, command histories, recursive gets, automatic

anonymous logins and more.

Install ncftp if you use FTP to transfer files and you’d like to try

some of ncftp’s additional features.

헤더에는 여러분이 채워넣을 필요가 있는 표준적인 필드를 담고 있습니다.

여기에는 몇 가지 주의할 것이 있습니다. 필드에는 반드시 위의 예와 같이

채워야 합니다. 다음은 이에 대한 설명입니다.

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 이것은 헤더 아이템이 아니지만, 여기서 설명해 두어야 한다.

당신의 패키지, 서브 패키지마다 설명을 하나씩 필요로 할 것이다. 이것은

패키지에 대해서 참고적인 설명을 쓰는데 사용하는 것이고 여러 줄에 걸쳐

쓸 수 있다:

2) 명령 실행 부분

이 부분은 rpm명령이 어떤 과정을 거쳐 파일을 만드는 지 그 과정을 적어두는

곳입니다. 이곳에 설정을 어떻게 하느냐에 따라 과정이 약간씩 달라집니다.

전형적인 rpm 과정은 원 소스를 풀고, makefile을 실행하여 컴파일하고 그것을

가지고 rpm을 만든 후 그 컴파일된 소스들을 지우는 것입니다. 이에 따라

spec의 명령 실행 부분이 편집하면 되는 것이죠.

이 부분에서 쓰이는 명령들- 여기서는 메크로라는 단어를 쓰게 됩니다 -을

보도록 하겠습니다.

다음은 ncftp의 예제입니다.

%prep

%setup -q

%build

CFLAGS=”$RPM_OPT_FLAGS” ./configure –prefix=%{prefix}

make

%install

rm -rf $RPM_BUILD_ROOT

mkdir -p $RPM_BUILD_ROOT/usr/{bin,man/man1}

make prefix=$RPM_BUILD_ROOT/usr install

mkdir -p $RPM_BUILD_ROOT/etc/X11/wmconfig

install -m644 $RPM_SOURCE_DIR/ncftp.wmconfig

$RPM_BUILD_ROOT/etc/X11/wmconfig/ncftp

%clean%clean

rm -rf $RPM_BUILD_ROOT

%files

%defattr(-,root,root)

%doc *README WHATSNEW-3.0 COPYING

%config(missingok) /etc/X11/wmconfig/ncftp

/usr/bin/ncftp

/usr/bin/ncftpget

/usr/bin/ncftpput

/usr/bin/ncftpbatch

/usr/bin/ncftpls

/usr/bin/ncftpbookmarks

/usr/man/man1/ncftp.1

/usr/man/man1/ncftpget.1

/usr/man/man1/ncftpput.1

/usr/man/man1/ncftpbatch.1

/usr/man/man1/ncftpls.1

가. %Prep

이곳에서부터 명령 부분이 시작됩니다.

이것은 명세 파일의 두번째 단락입니다. 이것은 소스를 빌드할 준비를

하는데 쓰입니다. 여기에서는 여러분이 소스 패치, make를 실행과 같은

셋업하는데 필요한 것들을 할 수 있습니다.

한가지 주의할 점: 각각 단락에는 실행할 쉘 스크립트가 위치하여야 합니다.

여러분은 간단히 소스를 풀고 패치할 쉘스크립트를 만들어 %prep 뒤에 위치

시킬 수 있습니다. 이것에 도움이 되도록 매크로를 만들어 두었습니다.

나. %setup

매크로의 첫 번째는 %setup 매크로입니다. 이것은 간단한 양식으로써

(명령행 옵션은 없습니다), 소스를 풀고 소스 디렉토리로 들어가는 것입니다.

여기에는 다음과 같은 옵션이 있습니다:

-n name 에서는 리스트된 이름에 빌드할 디렉토리의 이름을 정하는데,

기본값은 $NAME-$VERSION이다. 다른 가능성이 있는 $NAME,

${NAME}${VERSION} 또는 사용하는 tar 파일이 올 수도 있다.

(명세 파일 안에 있는 “$” 변수는 실제 변수가 아니라는 점에 주의하기

바란다. 그것은 실제로 샘플 이름이 위치할 곳을 나타내는데 쓰인다.

여러분은 변수가 아닌 패키지의 실제 이름과 버전을 사용할 필요가 있다.)

-c untar를 실행하기 전에 디렉토리를 만들고 그곳으로 이동하는 것이다.

-b # 는 그 디렉토리로 이동하기 전에 소스#의 압축을 풀 것이다.

(untar) (-c와 함께 사용할 수는 없다.) 이것은 여러개의 소스 파일이

있을 때만 유용하다

-a # 는 디렉토리로 이동한 후에 소스#의 압축을 풀 것이다.

-T 옵션은 압축을 푸는 기본 기능을 무시하고 압축 풀린 소스 파일을 얻기

위하여 -b 0 또는 -a 0 를 필요로 한다.부차적인 소스가 있을 때 이

옵션이 필요하다.

-D -D 는 소스를 풀기 전에 디렉토리를 지우지 않는 옵션이다. 이것은

여러분이 하나 이상의 셋업 매크로를 가지고 있을 때만 유용하다. 이것은

셋업 매크로 중 첫번째 것을 사용한 후에 쓰인다. (첫번째에 있으면 절대

안된다.)

다. %patch

사용 가능한 매크로중 다음으로는 %patch 매크로입니다. 이 매크로는

소스에 패치를 가하는 과정을 자동화 하는 것을 돕습니다. 여기에는 몇 가지

옵션이 있습니다.

다음에서 #는 foobar-1.0.patch(패치파일)로 대체합니다. 이것은 위에서

만든것과 같은 패치파일이라고 보면 됩니다.

-p #는 패치 명령(patch(1))을 strip할 디렉토리의 수를 지정한다.

-P 의 기본 기능은 패치를 적용하는 것이다. 이 플래그는 기본 기능이고

압축 풀린 메인 소스 파일을 얻기 위해서 0이 하나 필요하다. 이 옵션은 첫

번째 매크로와 다른 숫자를 필요로 하는 두번째 %patch 매크로에서 유용하다.

여러분은 역시 실제 명령을 내리는 대신 %patch# 를 쓸 수 있다:

%patch # -P

라. %build

%build 매크로에서 여러분이 포함하고자 하는 모든 것입니다.)은 쉘을

통하여 실행하는 것입니다. 여기서 여러분이 원하는 모든 형태의 매크로에

대해서는 예제를 보기 바랍니다.

이 단락에서는 실제로 어떤 매크로가 있는 것은 아닙니다. 여러분은 압축 풀린

소스를 가지고 있을 때 사용하기 원하는 소프트웨어를 빌드하고, 그것을

패치하고 그 디렉토리로 이동하는 등의 어떠한 명령이든지 여기에 넣어야

합니다. 이것은 명령들의 쉘에 전달되는 또다른 셋으로써, 어떠한 쉘

명령이든지(설명을 포함해서) 여기에 쓸 수 있습니다. 여러분의 현재 작업

디렉토리는 각각의 단락마다 소스 디렉토리의 최상위 레벨 디렉토리로

리셋되므로, 따라서 이것을 기억하기 바랍니다. 여러분은 필요하다면 서브

디렉토리로 이동할 수 있습니다.

마. %install    

이것 역시 실제 어떠한 매크로가 아닙니다. 여러분은 기본적으로 설치하는데

필요한 어떠한 명령이든지 여기에 넣어야 합니다. 여러분이 빌드하는 패키지

안에서 make install을 사용할 수 있다면, 여기에 넣어 두도록 합니다.

아니면, 여러분은 make install에 쓰일 makefile을 패치하거나

make install을 여기서 할 수 있습니다. 또는 수동적인 쉘 명령으로 설치할

수도 있습니다. 여러분은 현재 디렉토리가 소스 디렉토리의 가장 상위

디렉토리가 된다는 것을 생각하여야 합니다.

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

여러분은 바이너리 패키지의 설치나 제거 전후에 스크립트를 넣을 수 있습니다.

주된 이유는 공유 라이브러리를 담고 있는 패키지를 설치하거나 제거하고 나서

ldconfig와 같은 명령을 실행하기 위해서입니다. 각각의 스크립트에 대한

이 매크로들은 다음과 같습니다:  

%pre 설치하기 전에 실행되는 스크립트이다.

%post 설치한 후에 실행되는 스크립트이다.  

%preun 제거하기 전에 실행되는 스크립트이다.

%postun 제거한 후에 실행되는 스크립트이다.

이 단락의 내용은 #!/bin/sh 를 필요로 하지 않더라도 어떠한 쉘 스타일의

스크립트가 될 수 있습니다.

사. 파일에 관련된 메크로들  

여기는 여러분이 반드시 파일을 반드시 리스트해야 하는 단락입니다. RPM은

make install의 결과로 어떠한 바이너리가 설치되는지 알 방법이 없습니다.

이것을 할 수 있는 방법은 “없습니다”. 어떤 이는 패키지를 설치 전후에

find를 실행하기를 제의하기도 하였습니다. 그러나 다중 사용자 시스템에서는

패키지 빌드가 이루어지는 동안 패키지 자체와는 아무런 관련이 없는 다른

파일이 생성될 수 있기 때문에 받아들이기 어렵습니다.

여기에는 특별한 작업에 사용 가능한 몇 가지 매크로가 있습니다.  

여기에서 설명합니다.:

%doc 여러분이 바이너리로 설치하기를 원하는 소스 패키지 내의 문서를

표시하는데 사용된다. 문서는 /usr/doc/$NAME-$VERSION-$RELEASE에 설치될

것이다. 여러분은 매크로를 써서 명령행에서 여러 문서를 리스트하거나,

모두 각각 매크로를 써서 리스트할 수도 있다.

%config 는 패키지에서 설정 파일을 표시하는데 사용한다. 여기엔

sendmail.cf, passwd와 같은 파일을 포함한다. 여러분이 나중에 설정

파일을 담고 있는 패키지를 제거하고자 한다면, 수정하지 않은 파일은 모두

제거되고 수정된 파일은 .rpmsave 를 붙여 이름을 바꾸어 둔다. 여러분은

역시 이러한 매크로로 여러 개의 설정 파일을 리스트할 수 있다.

%dir 파일 안의 패키지에 포함되는 파일 리스트 안의 단일 디렉토리를 표시한다.

기본값으로, 여러분은 디렉토리 이름을 %dir 없이 나열할 수 있다,

디렉토리의 모든것은 파일 리스트 안에 포함되고 나중에 패키지의 한

부분으로 설치된다.

%files -f <filename> 로는 소스의 빌드 디렉토리 안에 있는 몇몇 임의의

파일에서 여러분의 파일을 리스트할 수 있다. 이는 여러분이 파일

리스트를 직접 빌드할 수 있는 패키지를 가지고 있는 경우에 좋다. 여러분은

여기 있는 파일 리스트만 포함시키고, 여러분은 특별히 파일을 리스트할

필요가 없다.

파일 리스트에서 가장 주의해야 할 것은 디렉토리 리스트입니다. 여러분이

실수로 /usr/bin을 써 두었다면, 여러분의 바이너리 패키지는 여러분

시스템의 /usr/bin 안의 모든 파일을 담게 될 것이다. 이 디렉토리

리스트는 소스의 makefile를 읽어서 확인하면 됩니다. 파일리스트를 만들기

위해서는 makefile파일을 참조하는 것과 설치과정의 출력 내용을 보고

만드는 방법이 있습니다.

3) %changelog 부분

다음에 패칭을 가하거나 프로그램을 개선하여 새롭게 내 놓을 사람들을 위해

이 부분을 만들어 둡니다. 다음은 ncftp의 %changelog 부분입니다.

* Sun Mar 21 1999 Cristian Gafton <gafton at

redhat.com>

– auto rebuild in the new build environment (release 3)

* Wed Feb 24 1999 Bill Nottingham <notting at

redhat.com>

– return of wmconfig

* Tue Feb 23 1999 Bill Nottingham <notting at

redhat.com>

– 3.0b18

* Fri Feb 12 1999 Bill Nottingham <notting at

redhat.com>

– 3.0b17

* Wed Dec  2 1998 Bill Nottingham <notting at

redhat.com>

– 3.0b16

* Wed Nov 18 1998 Bill Nottingham <notting at

redhat.com>

– add docs

* Thu Nov  5 1998 Bill Nottingham <notting at

redhat.com>

– update to 3.0beta15

* Thu Aug 13 1998 Jeff Johnson <jbj at redhat.com>

– build root

* Fri Apr 24 1998 Prospector System <bugs at

redhat.com>

– translations modified for de, fr, tr

* Wed Apr 08 1998 Cristian Gafton <gafton at

redhat.com>

– compiled for Manhattan

* Fri Mar 20 1998 Cristian Gafton <gafton at

redhat.com>

– updated to 2.4.3 for security reasons

* Wed Nov 05 1997 Donnie Barnes <djb at redhat.com>

– added wmconfig entry

* Wed Oct 21 1997 Cristian Gafton <gafton at

redhat.com>

– fixed the spec file

* Fri Oct 10 1997 Erik Troan <ewt at redhat.com>

– updated to ncftp 2.4.2

* Thu Jul 10 1997 Erik Troan <ewt at redhat.com>

– built against glibc

* Tue Mar 25 1997 Donnie Barnes <djb at redhat.com>

– Rebuild as Sun version didn’t work.

6] RPM으로 패키지 만들기

여러분이 spec(명세) 파일과 필요에 따라 patch파일(이것은 SOURCES 디렉토리에

foobar-1.0.tar.gz 소스파일과 같이 둡니다.)을 갖게 되면, 여러분은 패키지를

빌드할 준비가 된 것입니다. 다음과 같이  명령행에서 명령을 내리면

PRM 바이너리 파일과 RPM 소스파일(SRPM)이 만들어 집니다.

rpm -ba foobar-1.0.spec

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

p 는 명세 파일의 prep 단락을 실행한다는 것을 의미한다.

l 은 리스트 체크이다.  

c 는 prep를 하고 컴파일한다. 이것은 여러분이 어떠한 소스를 빌드해야 할지

정확하지 않을 때 유용하다. 소스를빌드하고 RPM을 사용하기 시작할 때까지는

여러분이 소스만 가지고 작업할지도 모르기 때문에 쓸모 없게 보인다.

그렇지만 RPM을 사용하는데 익숙해지면, 여러분은 이것을 사용할 때. 실례로써

찾을 수 있을 것이다.

i 는 prep 컴파일, 설치를 한다.

b 는 prep 컴파일, 설치와 바이너리 패키지만 만든다.

a 는 소스와 바이너리 모두 만든다.

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

(이것에 대한 자세한 내용은 전에 보여드린 –help 파일 부분을 보시기 바랍니다.)

–short-circuit 은 특정한 단계를 바로 건너뛴다. (c와 i에서만 쓸 수

있다.)

–clean 은 작업이 끝나면 빌드 트리를 지운다.

–clean 은 작업이 끝나면 빌드 트리를 지운다.

–keep-temps /tmp에 만들어진 모든 임시 파일과 스크립트 을 그대로 둔다.일

여러분은 -v 옵션을 사용하여 실제로 tmp에 어떠한 파일이 만들어지는지

볼 수 있다.

–test 는 실제 어떠한 단계도 실행하지 않는다, 다만 임시로 보존한다.

7] 만든 후에 테스트해 보기

위의 과정을 거치면 SRPM 파일과 RPM 파일이 생깁니다. 이 중에서 RPM파일을

다른 리눅스 시스템에서 설치하고 잘 돌아가는지 확인해 보는 과정이 있다면

더 정확한 테스트가 될 것입니다. 그러나, 그렇게 하기는 어려운 일입니다.

어찌되었든 자신의 시스템에서 rpm파일을 시험해 본다는 것은 정확하지 않을 수

있으며 권장하지도 못할 부분이라 하겠습니다.

4. RPM 을 다른 운영체제에서 만드는 방법

RPM은 인텔 i386, 디지탈 알파 리눅스, 스팍용 패키지를 만드는데 사용할 수

있습니다. RPM은 SGI와 HP 웍스테이션에서도 잘 동작한다고 보고되었습니다.

여기에는 패키지를 모든 플랫폼에서 쉽게 빌드할 수 있는 몇 가지 특징이

있습니다. 첫 번째 것으로는 rpmrc의 “optflags” 지시자가 있습니다.

여기에서는 소프트웨어를 빌드할 때 아키텍처에 종속된 플래그를 세팅할 수

있습니다. 명세 파일 안에 있는 다른 기능으로 “arch” 매크로가 있습니다.

그것은 여러분이 만드는 아키텍처에 의존되는 서로 다른 것들을 다루는데 사용할

수 있습니다. 또다른 기능으로 헤더의 “Exclude” 가 있다.

해더 부분에 다음을 추가

ExcludeArch: axp

스크립트 부분에 다음과 같은 메크로 추가

%ifarch axp  # 추가 되어야 할 부분

%patch1 -p1  # 이 부분은 patch 부분

%endif

이제는 i686도 가능해졌습니다. 그러므로, 686급 이하의 범용을 만들려면

i386옵션을 붙이거나 그대로 만들고, 자신의 시스템에 맞추기 위해서는 i686과

같은 옵션을 붙여 줍니다.

5. 자신이 만들 RPM 파일을 배포판 패키지에 포함시키기

만들어진 RPM은 개인 용도로 쓰이거나 ftp에 올려 다른 사람들이 공유할 수 있도록

할 수 있습니다. 아니면 자신이 새롭게 CD를 구성할 수도 있습니다. 그러기

위해서는 RPMS 디랙토리에 새로운 파일을 두고 다음과 같이 hdlist를 생성해

주어야 합니다.

새로운 hdlist 파일 생성하기

CD로부터 설치할 때 CD에 있는 설치 프로그램은 어떤 RPM 패키지들이

사용가능한지를 기술하는 RedHat/base/hdlist 파일에 의존합니다. hdlist 파일은

misc/src/install/genhdlist 로 생성할 수 있습니다. 이 프로그램은 하나의

인수로 배포판의 루트 디렉토리의 이름만을 넘겨주면서 실행해야 합니다. 이것이

그 프로그램을 호출하는 updateHdlist 스크립트입니다.

#!/bin/bash

RHVERSION=5.1

ARCH=i386

echo generating hdlist…

CDDIR=/jaz/redhat-${RHVERSION}

GENHDDIR=${CDDIR}/${ARCH}/misc/src/install

chmod u+x ${GENHDDIR}/genhdlist

chmod 644 ${CDDIR}/${ARCH}/RedHat/base/hdlist

${GENHDDIR}/genhdlist ${CDDIR}/${ARCH} || echo “*** GENHDLIST FAILED ***”

exit 0

위의 스크립트는 5.1버젼용입니다. 만약 실행이 되지 않는다면 구성을 보시고 직접

과정을 밟아 주시면 됩니다.

6. 한글 패치시 주의할 점

한글 패치를 할 때는 다음의 과정을 거칩니다.

가. 먼저 한글이 자체적으로 지원하는지 확인한다.

나. 한글패치가 되었는지 확인한다.

다. diff로 한글패치를 만든다.

라. rpm 파일을 생성한다.

요즈음에는 여러 프로그램에서 한글이 자체적으로 지원이 되고 있습니다.

따라서, 패치시 그것을 고려하여 쓸데없이 한글 패치를 가하는 일이 없도록

하여야 할 것입니다. 한글 패치는 hanIM 등의 한글입력기가 쓰일 수 있도록

합니다. 수동으로 한글이 인식되도록 하는 것이죠.

참고 – hanterm 에서는 한글인식이 되지만 xterm 에서는 한글인식이 되지

않습니다. 그것은 xterm에서 한글코드를 인식할 수 있도록 설정이 되어 있지

않기 때문입니다. 그리고, X윈도우에서 한글 로케일이 설정이 되어 있지 않으면

모든 한글이 깨어져 나옵니다. 프로그램 자체에서 한글이 지원되어도 말이죠.

이것에 대한 것은 KLDP에 있는 천리안 리눅스 세미나 자료를 참고하시거나

다른 한글 관련 파일들을 참고하시기 바랍니다.

7. 글을 마치면서

이번의 글은 박상완 형님의 RPM 세미나를 받고나서 정리하여 남기는 것입니다.

따라서 미비한 부분도 있고, 그렇기 때문에 기존의 HOW-TO 문서들을

참고하였습니다. 세미나를 주신 박상완 형님께 감사를 드리고, 이번에 이 문서와

관련하여 제가 세미나를 드릴 때 열심히 들어주신 HLUG 여러분께 감사의 말씀을

드립니다.

아울러 이 글에 대해 수정해야될 부분이 있거나 조언이 있으시면 저에게 메일을

주시기 바랍니다.  

8. 저작권

일반 HOW-TO 문서와 같습니다.