1. 레드햇 패키징 레드햇의 패키지는 아주 뛰어나다고 생각한다. 나만의 생각일런지 모르지만 많 은 사람들이 레드햇 그리고 데비안 패키징에 참여 했으면 하는 바램도 있다. 나는 레드햇 패키징에 대해서 밖에 지식이 없기 때문에 그 부분에 대해서만 글 을 적을려고 한다. 데비안 패키징은 또 다른 사람이 나설 것이라 믿는다. RPM 패키지를 다루는 전박적인 방법등은 이미 한글로 번역된 RPM 메뉴얼 페이지 와 RPM 하우투 문서를 보면 간단히 알 수 있을것이다. 한글이니까. 그냥 나는 패키징을 하는 꽁수 정도의 글을 적을 것이다. 이미 하우투 문서에 많은 부분이 한글로 번역 되어서 읽어 주기만을 손꼽아 기다리고 있을테니까 중 복은 피할려고 하지만 아마 못 피할꺼 같음. 흐흐 2. 패키징을 위한 준비 패키징에서 기본으로 쓰는 디렉토리들은 /usr/src/redhat 이하와 /var/tmp 이다. 물론 바꿀수 있다. /usr/lib/rpmrc 를 살펴 보기 바란다. 여기에 기본적인 설정 이 들어간다. 우리는 /etc/rpmrc 라는 파일을 만들어서 설정을 바꾸어 줄수 있 다. (lib 아래는 건드리지 않기 바라다.) topdir: /pkg/redhat 이런식의 설정이 가능하다. 그외 여러가지 설정 방법은 man page 또는 하우투를 참고 하기 바란 다. 또는 rpm --showrc 를 하면 쓸수 있는 설정들을 볼 수 있을것이다. 가장 쉽게 패키징에 익숙해지는 방법은 남이 한것을 보고 따라해 보는것이다. 그것만큼 빠르게 배우는 길이 없다. 다른 것도 마찬가지다 쉘 스크립트, 프로그 래밍... 당장 자신이 직접 만든다는 생각보단 남이 만들어 놓은 spec 파일을 찬 찬히 뜯어 보고 그것을 바꿔 가며 시도해 보는것이 좋을것이다. /usr/src/redhat 이하의 디렉토리 구성을 잠깐 살펴 보자. 총 다섯개의 디렉토 리가 있다. 하나 하나 어떤 연활을 하는지 살펴 보기로 하자. BUILD : 패키지를 만들때 이곳에 소스를 풀고 여기서 컴파일을 하게 된다. RPMS : 만들어진 RPM 패키지 화일이 이 디렉토리에 저장된다. SOURCES : 패키지를 만들기 위해 필요한 소스 파일들이 이곳에 위치한다. SPECS : 패키지 제작을 위한 가장 기본적인 파일이 여기에 위치한다. spec 파 일이라고 하는것인데 패키지를 만드는 모든 순서와 정보를 기록한다. SRPMS : RPM 패키지와 함께 만들어지는 소스 패키지가 위치하는곳이다. 3. spec 파일 구성하기 우리가 할일은 소스 (바이너리만 있어도 아무런 상관이 없다 후에 설명 하겠다) 를 가져와 SOURCES 디렉토리에 놓고 spec 파일을 만드는 것이다. 쉽지만은 않 다. 하지만 어떻게 보면 쉽다고 생각한다. spec 파일의 구성은 가장 힘들고 또, 짜증이 나는 부분이기도 하다. 그리고 수만가지 꽁수가 난무하는 곳이기도 하고 별의 별 쉘 명령이 쓰이는곳이다. 아마 스크립트를 잘만들줄 안다면 한결 쉽게 사용할수 있을것이다. 그야말로 스크립트를 짜는 기분으로 하면 된다. 중요한것 하나 말하고 싶은것이 있다. 절데로 소스를 변경하지는 말라는 것이다. 소스를 변경할 부분이 있다면 patch 로 만들어서 패키지를 만들때 패치를 하는 식으로 사용하라. 소스 자체를 건드리게 된다면 아마 나중에 후회를 할 것이다. 왜 그런것인지는 곰곰히 생각해보라. 하지만 이 말을 그냥 넘기지는 않는게... spec 파일의 구성은 패키지에 관한 정보 그리고 만들고 설치하기 마지막으로 설 치된 파일들을 하나로 묵기 이렇게 구성된다고 보면 된다. 우선 패키지에 대한 정보를 적는 부분을 살펴 보도록 하자. 여기서 설정한것들은 rpm -qi 으로 볼수 있는 것들이다. 솔직히 그렇게 신경 쓸 부분은 아니라고 본다. 그 프로그램에 대한 정확한 정보를 전달 한다고 생각하면 된다. 아 의존성 부분은 제데로 해야지 ^^ Summary: 간략한 설명을 한줄로 적는다. 안 적으면 너무 허전하다. 여긴 왠 만 하면 적는것이 좋다. Name: 프로그램의 이름을 적는곳이다. 틀리게 적으면 평생 고생한다. Version: 버젼을 적는곳이다. 괜히 심심하다고 올려서 적거나 하지 말기를! Release: 이곳은 릴리즈 번호인데 패키징의 실수로 재패키징을 했다면 올라 간다. 머 안 올려도 상관 없는데 괜히 딴 사람 주고 나서 버그 고 쳤는데도 안 올리면 꽤나 욕 먹을꺼라고 이 연사 주장합니다. Group: 속한 그룹을 적는곳이다. glint 같은 GUI 유틸에서 사용하기 편하 기 위함 이기도 하고 또한 패키지를 구분하기 위함이기도 하다. Source: 소스의 이름을 적으면 된다. 보통 구할수 있는 출처가 함께 기록 된다. ftp://ftp.foobar.com/pub/foobar.tgz 이런식으로 말이다. 꼭 가져온 곳을 정확하게 적지 않아도 된다. 실제 SOURCE 디렉토 리에 위치한 파일과 이름만 같으면 되다. 소스가 한개가 아니라면 Source1,Source2 이런식으로 하여 적어 주면 된다. Patch: 역시 패치 파일의 이름을 적으면 된다. 위를 참고하라. Copyright: 이 프로그램의 라이센스를 나타낸다. 이 프로그램의 라이센스가 먼지 모르지만 배포해도 된다면 distributable 이런식으로 쓰면 된다. 모르면 그냥 저렇게 크크, 상용은 아예 패키징 하지 말것!! BuildRoot: 이곳은 패키지를 설치할때 시스템에 덮어 쓰는것이 싫다면 적어 주고 닭질을 좀 하면된다. /tmp/program 이런식으로 정해주면 무 리가 없을것이다. 이 한줄을 넣은것 때문에 닭질이 시작된다. 그 것도 개닭질이 말이다. 흐흐 Icon: glint 같은 패키지 관리 도구 하에서 아이콘을 나타내기 위해 사 용한다. gif 포맷이어야 하며 SOURCE 디렉토리 하에 위치 하여야 한다. 지정해주고 없다면 패키지는 만들어지지도 않는다. Packager: 패키지를 제작한 사람의 이름, 이메일 주소 정도를 적으면 된다. 머 보이는거 아니니까 안 적어도 되고 지 맘이지 머 ^^ Requires: 의존성 관계를 설정한다. 이 패키지는 어떠한 패키지에 대해 의존 성이 있다는걸 나타내는 것이다. 단 패키지간에만 의존성을 걸 수 있다. 패키지위 버젼에도 역시 의존성 관계를 설정 할 수 있는데 foobar >= 1.0 또는 = 1.0 이런식의 설정이 가능하다. 문제는 높 거나 같은 만 설정할수 있다는것이다. 흐윽 덕분에 HanX 패키징할 때 문제가 좀 있었다. 히잉 T_T %description 패키지에 관한 긴 설명을 적는다. Summary 와 똑같다고 욕하는 사 람은 없다. 그래도 열심히 길게 적어 주는게 좋다고 생각한다. 이 유는 rpm -qi 로 봤을때 짧으면 허전하니까. 참 한글로는 적지 말 자. 한국인만 쓰는것도 아니니까 흐흐 %changelog 무엇이 바뀌었는지 알려 주고자 할때 사용할수 있다. 괜시리 릴리 즈 버젼이 1 올랐습니다. 이런건 적지 말기 바란다. 무지 욕먹음 이번에는 패키징할 프로그램의 소스를 풀고 컴파일 그리고 설치를 하는 과정이 다. 이 곳은 정말 별의별 꽁수가 동원되는 곳이다. 그리고 사실 이 부분은 빼 먹어도 패키징은 된다. 패키징을 할때 필요한것은 위에 설명한 정보 부분과 마 지막에 나올 파일을 찾아내서 슥슥 묶어 버리는 곳이니까 말이다. 이 부분도 세개로 나누어 볼수 있다 첫째가 소스를 풀고 패치를 가하고 하는 컴 파일 이전의 준비과정, 두번째는 실제로 컴파일을 하는 과정, 마지막으로 컴파 일한 프로그램을 설치하는 과정이다. (왜 BuildRoot 를 쓰면 개닭질을 하게 되 는지 얼마 안 있어서 알게 될것이다.) 이 부분에서는 rpm 안에 정의된 변수를 많이 사용하게 될것이다. 대충 한번 말해 볼까나? $RPM_SOURCE_DIR: 보시다 시피 SOURCES 디렉토리를 나타낸다. $RPM_BUILD_DIR : 컴파일을 하는 디렉토리이다. BUILD 디렉토리 및 $RPM_BUILD_ROOT: 위 설정 부분에서 BuildRoot 를 쓸때 그 디렉토리를 나타낸다. $RPM_OPT_FLAGS : 컴파일 할때 쓰이는 옵션이다. /usr/lib/rpmrc 를 보면 알 수 있을것이다. optflags: i386 -O2 -m486 -fno-strength-reduce 이런식으로 지정되어 있는 부분이다. $NAME : 프로그램의 이름을 나타낸다. 우리가 지정했던 이름 말이다. $VERSION : 버젼을 나타낸다 역시 우리가 지정했던 버젼이다. ^^ 이 정도만 알고 이제 실제적으로 구성하는 법을 살펴 보도록 하자. 우선 소스를 풀고 패치를 가하는 그러한 컴파일 이전의 준비를 하는 과정이다. %prep 이라는 명령어를 통해서 준비과정에 들어간다고 말한다. 여기서 쓰이는 rpm 내부 명령어로는 %setup 그리고 %patch 가 있다. 이 두개만 쓰면 딴건 쓸 명령이 없다고 본다. (저걸 편리 루틴이라고 부른다고 만용형에게 들었다. 그게 먼지 모르지만 흐흐흐) 사실 저러한 명령을 사용하지 않아도 된다. 그냥 일반적으로 하는식으로 (기본적으로 %prep 이후의 명령은 BUILD 디렉토리 및에서 이루어 지게 된다.) tar xvzf foobar.tgz cd foobar 이런식으로 적어도 상관이 없다. 어차피 만드는사람 마음이다. 또한 %setup 명 령으론 tgz 이외의 파일을 풀수가 없기 때문에 어쩔수 없이 저렇게 사용해야 하 는 경우도 많다. 그럼 %setup 명령의 사용에 대해서 알아보자. %setup 명령이 내려지게 되면 rpm 은 Source 에서 지정한 이름과 같은 파일을 찾게 된다. 그리고 그 파일을 BUILD 디렉토리 및으로 풀고 그 디렉토리로 이동하게 되있다. 그런데 여기서 재밌는건 무조건 $NAME-$VERSION 이런식의 디렉토리를 찾게 된다는 것이다. 즉 rpm 이 원 하는 이름으로 디렉토리가 만들어지지 않는다면 우리가 지정해 줘야 한다. 이때 에 -n 옵션을 쓴다. %setup -n foobar 이런식으로 지정한다면 우리의 호프 rpm 은 foobar 란 디렉토리를 찾아 기어 들어가게 될것이다. 하나더 말하자면 정말 짜증나는 경우인데 압축을 풀면 디렉토리를 만들고 기어 들어가는게 아니라 그 디렉토리에다 데고 마구 풀어 버리는 몰상식한 것들이 있다. 이럴때는 어떻게 해야 하는가? -c 옵션을 사용하라. -n 옵션에서 지정한 이름으로 디렉토리를 만 들고 그 곳으로 들어가서 압축을 푼다. 그 외에 -a 옵션과 -b 옵션이 있다. 이것들은 압축된 소스가 여러개 있을때 쓰 는 옵션인데 -a 는 첫번째 소스가 풀린 디렉토리로 기어 들어간 후에 압축을 푸 는것이고 -b 는 안 기어 들어가고 밖에서 풀게 된다. 근데 -c 옵션이랑은 같이 사용할 수가 없다고 하우투에서 주장하고 있다. 이건 이만 줄이고 (와 길다.) %patch 를 보기로 하자. 역시 %setup 부분과 마찬가지로 손으로 열라게 적어주 어도 된다. 뭔 상관인가 모로 가도 서울만 가면 되는거 아닌가. 이상한 예기는 그만 하고 다시 다시... 이 명령에서 알아야 할 옵션은 -p 하나면 된다. -p 는 도데체 무었인가? 머라고 말해야 할지 난감하다. 잠시 나우누리에 올라온 글을 뒤지러 휘잉~ 역시 나우에 답이 있었다. "없앨 슬래쉬 갯수" 라고 한는데 도데체 먼 말인가 예가 있으니 한번 다시 긁어와 봐야징. 흐음 도저히 긁어서 이해할 글이 아니다. 한번 그냥 적어 봐야지 ^^; patch 파일을 보면 맨 위쯤에서 이러한 줄을 발견할 수 있을것이다. --- usr/src/foobar/foobar.c.orig Mon Aug 11 02:10:23 1997 +++ usr/src/foobar/foobar.c Mon Aug 11 02:03:59 1997 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 패치할 파일의 위치를 나타네는데 만약 우리가 /usr/src/foobar 라는 디렉토리 에 위치하고 있다면 patch < foobar.patch 이런식으로 아무리 해봐도 파일을 찾 을수 없다는 에러가 날것이다. 죽어라 현재 위치에서 usr/src/foobar 란 디렉토 리를 찾을테니까 말이다. 이런식으로 하면 된다. patch -p3 < foobar.patch 이 해가 가는가? usr/src/foobar/foobar.c 라는 파일을 찾으라는 것을 p3 을 줌으 로써 슬래쉬 3개 만큼 투욱 잘라내고 foobar.c 를 찾으라고 하는것이다. 이것이 왜 rpm 패키징에서 자주 쓰이는가? 기본적으로 %patch 명령을 실행하는 위치는 BUILD 아래에 압축이 풀린 디렉토리이다. patch 파일의 내용을 보면 보 통 foobar/src/foobar.c 이런식으로 프로그램이 풀릴 디렉토리까지 포함되 있다. (도데체 내가 먼 말을 하는거지? 그냥 가자.) 그래서 foobar/ 란 부분을 스윽 잘라서 src/foobar.c 로 만들어야 하는 일이 많을것이다. (이전 버젼부터 쓰던 patch 를 계속 쓰는 경우도 많고 디렉토리의 이름이 틀릴때도 많고 하니까) 그 래서 보통 %patch -p1 명령을 주고 사용한다. 직접 해보면서 몸에 익히면 된다. 이제는 빌드 그러니까 컴파일을 하는 과정이다. %build 란 명령으로 이 부분이 시작 되었음을 우선 rpm 에 알리게 된다. 일반적으로 컴파일을 하는 과정을 적 게 되는데 머 이런식이다. ./configure make 아주 간단하다. 보통 컴파일 하는식으로 적어주면 되는데 다만 configure 같은 것을 사용할때에 패키지의 파일들이 설치될 위치를 제데로 설정하고 머 CFLAGS 같은걸 잡아주면 된다. 여기서 RPM_OPT_FLAGS 라는게 쓰이는데 팬티엄 프로 같 은데서 컴파일을 할때 팬티엄 프로에 최적화되어 컴파일 된다면 486 사용자들은 참 쓰기 고달플것이다. 그래서 486 시스템에 맞추어 컴파일을 하게 되는게 보통 이며 CFLAGS=$RPM_OPT_FLAGS ./configure 이런식으로 할수 있다. 또는 이런식으 로도 할수 있다. make CFLAGS=$RPM_OPT_FLAGS 물론 이런식으로 사용하기 이전에 소스내의 Makefile 이 어떻게 구성되어 있는지 어떠한 FLAG 를 사용하는지 알아 두어야 한다 무작정 저런식으로 사용한다고 해서 제데로 되라는 법은 없으니까 make 하나로 모든 컴파일이 안 끝난다면? 일일이 적어 주면 된다. cd src ln -sf Makefiles/Makefile.Linux Makefile make sendmail cd ../mailstats rm -f Makefile make CFLAGS="$RPM_OPT_FLAGS -I../src -DNEWDB" LDFLAGS=-s mailstats cd ../rmail rm -f Makefile make CFLAGS="$RPM_OPT_FLAGS -I../src -DNEWDB" LDFLAGS=-s rmail 이런식의 개닭질을 할수도 있다. 짜증나도 어쩌겠는가 컴파일은 해야 되는디 머 꼭 이곳에서 컴파일만 하라는 법은 없다. 카피를 하고 파일 이름을 바꾸고 먼 짓을 해도 제데로만 되면 되는것이다. 모로 가도 서울만 가면 된다를 상기 하기 바란다. 근데 괜히 이상한짓 하나가 삐끗하면 처음부터 다시 해야 한다. 꼭 기억하기 바란다. 같은 프로그램 몇번씩 컴파일 하는건 정말 흐 이번에는 %install 설치 부분이다. 보통 make install 을 쓰거나 직접 파일을 일일이 카피하면 된다. 여기서 BuildRoot 를 사용했다면 개닭질을 하게 된다. 그냥 지나왔다면 make install 아주 간단하다. 필요한 파일을 구성하고 링크를 만들어야 하는곳은 링크하고 하는 자질구래한 일이다. echo "# sendmail.cw - include all aliases for your machine here." > \ $RPM_BUILD_ROOT/etc/sendmail.cw 이런식으로 괜히 파일 하나 만들기도 하고 흐흐. BuildRoot 를 사용할때의 닭 질 하는 방법만 적어 보겠다. 우선 BuildRoot 를 사용하다면 설치하기 이전에 이미 그 디렉토리를 사용하는 것이 있던 없던 지워주는것이 기본이다. rm -rf $RPM_BUILD_ROOT 간단하게 슬쩍 지우고 나서 설치할 디렉토리를 만들어 주어야 한다. 그냥 깐 다면 이미 디렉토리들이 대부분 만들어져 있기 때문에 별로 신경 쓰지 않아도 되겠지만 흐윽 하나도 안 만들어져 있으니 하나하나 만들어야 하는건 당연한 예기 아닌가. mkdir -p $RPM_BUILD_ROOT/usr/{bin,lib,man/man1} 재밌는걸 하나 발견했을것이다. { }로 묵은 부분 왜 저렇게 쓰는지 알 사람은 이미 다 짐작했겠지만 묵기 이전의 부분 하위로 좌르륵 만들어 내는 것이다. 실제로는 $RPM_BUILD_ROOT/usr/bin, $RPM_BUILD_ROOT/usr/lib 이런식으로 만 들어지는 것이다. 아참 -p 옵션은 만들 디렉토리까지의 경로가 존재하지 않으 면 싸그리 다 만드는것이다. ^^ ($RPM_BUILD_ROOT 주의 하기 바란다.) 자 그리고 이제 파일을 설치 한다. make install 을 쓸까? 그러면 온통 시스 템에만 깔리고 $RPM_BUILD_ROOT 및으로는 전혀 안 들어갈텐데? 요런식으로 해 볼수 있다. 우선 Makefile 을 한번 살펴 보기 바란다. 젭싸게 install 부분을 살펴 보면 요런식으로 대부분 사용할것이다. install: foobar ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} foobar ${BINDIR} 이런식으로 대부분 변수?를 사용해서 한다. Makefile 위에서 이것을 다 정의 해 주게 되는데 그걸 슬쩍 바꿀수 있지 않겠는가? $BINDIR 은 어떻게 정의 되 어 있는지 한번 볼까나? BINDIR= ${DESTDIR}/usr/sbin 오 이렇게 되 있다. 흐 음 그런데 DESTDIR 은 아무것도 지정되어 있지 않다 그럼 실제 BINDIR 은 이 렇게 되겠구나 /usr/sbin, 후우 우리는 DESTDIR 을 지정해서 스윽 깔리는 위 치를 바꿀수 있을것 같다. 안 그런가? 요렇게 해보면 어떨까? make DESTDIR=$RPM_BUILD_ROOT install 후후 재밌지 않는가? BuildRoot 때문에 팔자에 없는 Makefile 도 실실 들여봐 야 하구 말이다. 모든 Makefile 에서 DESTDIR 을 쓰는건 아니니 것또한 살펴 보야야 한다. 전혀 저런걸 안 쓰는 Makefile 인데 BuildRoot 를 사용 하고 싶 다면? 어쩌겠는가 patch 파일이라도 만들어서 Makefile 을 고치는 수밖에, 한 가지 강조하지만 절데로 왠만해선 살고 싶으면 소스를 직접 건드려서 다시 압 축하고 하는일은 하지 않기 바란다. 그냥 패치로 만들어서 패키지를 만들때에 사용하고 원 소스는 변경하지 않는것이 좋다 대충 이해가 가는가? 꼭 make install 을 사용할 필요도 없다. cp 나 install 명령을 이용해서 직접 깔아 버려도 된다. for l in 1 2 3 4 5 6 7 8 9 n; do mkdir -p $RPM_BUILD_ROOT/usr/man/ko/man$l mkdir -p $RPM_BUILD_ROOT/var/catman/ko/cat$l if [ `ls --color=no| grep -c \\\\.$l` -gt 0 ]; then install -c -m 644 *.$l* $RPM_BUILD_ROOT/usr/man/ko/man$l fi done 별의 별 방법을 동원해서 일을 줄릴려고 하지 않는가? 이런식으로 사용해도 절데로 지장이 없다. 깔리기만 하면된다. 모로 가도 어디만 가면 된다고? 참 이거 주의해야 한다. 어떤 파일을 링크를 시켜야 하는 경우가 있을것이다. sendmail 같은걸 한번 만들어보면 온통 링크를 보게된다. 이때 주의 할점이 있다. ln -s $RPM_BUILD_ROOT/bin/foobar $RPM_BUILD_ROOT/lib/foobar2 저런식으로 링크 했다간 다시 패키징을 하는 불상사를 초래할것이다. 링크 정 보가 엉망으로 되기 때문이다. 실제로 패키지의 설치는 /bin 에다 되는데 링 크 정보는 $RPM_BUILD_ROOT의 bin 디렉토리에서 파일을 찾으니 돌아가시는 일 이지 무엇인가? 이런식으로 하기 바란다. cd $RPM_BUILD_ROOT/lib ln -s ../bin/foobar ./foobar2 이렇게 하면 풀패스가 안 적히니까 흐흣 (왠 꽁수지?) 어쨋든 이 부분은 정말 로 주의해야 한다. 누구처럼 컴파일을 몇번 다시 하기 싫다면 말이다. 꽁수 하나더, 컴파일 부분이 잘못되어서 다시 패키징 하여야 한다면 모를까 설치 부분을 잘못 적었거나 파일 지정 머 이러한 부분에서 에러나면 다시 컴 파일을 해야 한다고 생각하면 으 정말 미칠 노릇일 것이다. 이런 방법을 사용 하면 된다. BUILD 디렉토리에 컴파일된 파일들이 있는 디렉토리의 이름을 슬 적 바꾼다. %prep 부분에서 이름이 같은 디렉토리는 지워버리니까 대피 시키 는 것이다. 그런후 rpm -ba foobar.spec 같이 패키징을 시작한다. 소스파일의 압축을 풀고 패치를 한후에 컴파일에 돌입하기 직전 ctrl+z 를 누른다. 당연 히 작업은 멈출것이고 이미 컴파일된 내용을 그 디렉토리로 카피를 해버리면 흐흐 보통 이미 되 있으면 make 가 알아서 컴파일을 하지 않는다. 후후 이런 식으로 컴파일이 오래 걸리는 프로그램은 지겨운 컴파일 과정을 다시 하지 않 고 재패키징을 할수 있다. 자 그럼 다시 제자리로 돌아와서... 다 설치했으면 예의상 깔린 디렉토리를 지워줘야 하는거 아니겠는가? %clean 이라는 명령은 모든게 끝난후 정리 한다는것이니 기억해 두면 좋을것이다. %clean rm -rf $RPM_BUILD_ROOT 아 빼먹을뻔 했네요 패키지에 포함되는 스크립트에 대해 잠시 알아 보도록 하지요. RPM 패키지에는 4가지의 스크립트가 있습니다. 설치전, 설치후, 지 우기전, 지운후 이렇게 4가지인데 왜 필요하냐구요? 머 링크를 한데던지 라 이브러리를 넣은 패키지는 ldconfig 을 해주기도 하고 저의 i18n 패키지 같 은 경우는 원래 깔린것과 충돌을 피하기 위해 별짓을 다해 놓았지요. %pre 항목은 설치하기 이전에 실행할 스크립트입니다. 설치 이전에 이미 깔 려 있는 파일들을 백업 한다던지 머 다양한 용도로 사용할수 있습니다. 한번 예를 볼까요? if [ ! -d /usr/X11R6/lib/HanX ]; then mkdir -p /usr/X11R6/lib/HanX if [ -f /usr/X11R6/lib/libX11.a ]; then mv /usr/X11R6/lib/libX11.a /usr/X11R6/lib/HanX/libX11.a.orig fi mv /usr/X11R6/lib/libX11.so.6.1 \ /usr/X11R6/lib/HanX/libX11.so.6.1.orig fi HanX 패키지는 X윈도우의 라이브러리를 덮어 씁니다. 그러니까 원래의 파일들 을 백업을 시키는 수를 쓰고 있습니다. HanX 디렉토리 아래로 원 파일들을 이 동 시켜서 손상이 가지 않게 하지요. %post 는 설치후에 실행할 스크립트를 적는 곳이지요. 역시 HanX 패키지에서 사용 했던 것을 보기로 하지요. cd /usr/X11R6/lib ln -sf HanX/libX11.a . ln -sf HanX/libX11.so.6.1 . ldconfig HanX 패치된 라이브러리 들이 /usr/X11R6/lib/HanX 및에 libX11.so.6.1 이런 이름을 위치하게 됩니다. (원래 패키지와의 충돌을 피하기 위해서) 그것을 링 크를 이용해서 /usr/X11R6/lib 및에서 찾을수 있게 해주고 ldconfig 을 실행 하여서 라이브러리를 알아 먹게 해주지요. %preun 은 제거하기전에 행하는 스크립트를 적는곳이지요. %postun 은 패키지를 지운후에 쓰는 스크립트입니다. 보통 원래의 상태로 되 돌려 놓기 위해서 사용하겟지요? 역시 HanX 패키지에서 사용한것을 살펴 보겠 습니다. if [ -d /usr/X11R6/lib/HanX ]; then mv -f /usr/X11R6/lib/HanX/libX11.a.orig /usr/X11R6/lib/libX11.a mv -f /usr/X11R6/lib/HanX/libX11.so.6.1.orig \ /usr/X11R6/lib/libX11.so.6.1 rm -rf /usr/X11R6/lib/HanX fi ldconfig 백업했던 파일들은 원상복귀 시킨후에 ldconfig 으로 다시 라이브러리를 인 식시키지요 ^^; 라이브러리를 교체 했으니까요. 이 부분을 잘 사용하면 생각보다 재미있고 쉽게 패키지를 만들수 있습니다. 참 하나 주의 하세요. 씨디롬에 들어가는 패키지의 경우에요. 특정 파일을 건드려야 하는데 이 파일이 속한 패키지가 지금 만드는것보다 늦게 설치 된 다면? 에러만 보고 말겁니다. 알파벳 순으로 설치되는거 아시죠. 사람 정말 답답해 지는거죠. 흐윽 T_T 또 하나, cat 을 이용해서 파일에 내용을 추가 시키는 방법을 써봤는데 이게 잘 안되더군요. nh2ps 에서 사용한건데 그래서 결국엔 echo 를 이용했습니다. cat 이 씨디롬에서 install 이라는 프로그램과 링크가 되 있는데 흐 이게 제 데로 안 돌아가는건지 골 잡습니다. 후우 대충 끝났다고 보이는데? 이제 파일의 위치를 적어주는 부분이다. 제일 중요한 부분이다. 이게 없으면 패키징이 안되고 이것만 있어도 패키징이 된 다. 흐흐 그래서 바이너리만 있어도 패키징은 할수 있다는 말이다. ^^ %files 라는 명령이 내려지면서 파일의 위치를 찾는것은 시작된다. 정확해야 한다. /usr/doc/HOWTO/translations/ko/Assembly-HOWTO.gz /usr/doc/HOWTO/translations/ko/Installation-HOWTO.gz /usr/doc/HOWTO/translations/ko/Sound-HOWTO.gz /usr/doc/HOWTO/translations/ko/Firewall-HOWTO.gz /usr/doc/HOWTO/translations/ko/NET-3-HOWTO.gz /usr/doc/HOWTO/translations/ko/Sound-Playing-HOWTO.gz 이런식으로 일일이 다 적어 줘야 한다. 흐윽 또는 어느 디렉토리 이하의 모 든것을 지정하고자 하면 /usr/doc/HOWTO/translations/ko/mini 이렇게 디렉토리 이름을 적어 주면 그 이하는 싸그리 묵게 된다. 참 이부분에는 BuildRoot 를 썼다고 해서 $RPM_BUILD_ROOT 를 앞에 붙일 필 요가 없다. 알아서 다 하니까 ^^ 여기엔 몇가지 예약된 명령들이 있다. %config, %dir, %doc 이렇게 3개인데 (3개 밖에 없던가?) %config 은 설정 파일임을 나타낸다. 이것은 rpm -Uvh 로 설치될때 rpm 이 찾아서 같은 파일이 있다면 백업을 하게 된다. %config /usr/X11R6/lib/X11/app-defaults/Xmag-ko 이런식으로 사용한다. 이번에 %dir 이란 명령은 그냥 그 디렉토리만 넣을때 사용한다 그러니까 아까처럼 디렉토리를 지정하면 그 이하는 모두 패키지에 포함되게 되지만 %dir /usr/doc/HOWTO/translations/ko/mini 이런식으로 한다면 mini 디렉토리 및에 무엇이 있든간에 mini 디렉토리만 포함하게 된다. 마지막으로 %doc 이다. 언제 한번 /usr/doc 및을 가봤으면 수 많은 디렉토리들을 볼수 있을것이다. modules-2.0.0-5/ 머 이런식의 디 렉토리들이 널려 있는데 $NAME-$VERSION-$RELEASE 이런식의 디렉토리들인데 여기에 들어갈 파일들을 지정하는것이 %doc 이다. %doc 이런식 으로 지정된 파일들은 /usr/doc/$NAME-$VERSION-$RELEASE 및으로 들어가게 되는것이다. 어느 디렉토리 전체를 설정할수도 있다. 4. 마지막 패키지 만들기 패키지를 만드는 방법은 아주 간단하다. rpm -ba 이러면 끝이다. 물론 소스나 패치들이 다 제자리에 있어야 하고 spec 파일도 제데로 구성되 어 있어야 한다. 심심하고 할일이 없다면 rpm -ba --test 라는 명령을 우선 사용해 보는게 그나마 좀 소편할것이다. rpm -ba --sign 으로 패키지를 만들게 되면 PGP 사인을 넣게 된다. 사용할 keyring 의 위치를 /etc/rpmrc 에 정확히 지정해주어야만 한다. 주의 하기 바란다. 패키지를 모두 제작한후에도 PGP 사인은 첨가할수 있다. --resign 과 --addsign 을 사용하는데 전자는 말 그데로 다시 사인 하는 것 이고 후자는 현재 있는 사인 위에 또 하나 더 하는 것이다. 잘 구별해서 사 용하기 바란다. 누구처럼 두번씩 사인 하는 일이 벌어 지지 않도록... 5. 끝으로 별 시덥지 않은 강좌를 읽어 주셔서 감사합니다. 반말도 마구 남용하고 ^^ 이 글이 도움이 될런지 모르겟습니다. 솔직히 이미 하우투나 맨 페이지에 있는 내용인데 괜히 더 적은거 같기도 합니다. 별반 새로울께 없는 글을 또 한번 적는거 같아서... 어쨋든 도움이 되었으면 합니다.