데비안 새로운 관리자 안내서 --------------------------- Josip Rodin 번역: 류창우 번역: 양유성 version 1.2, 6 April 2002. ------------------------------------------------------------------------------- 저작권 ------ Copyright (C) 1998-2000 Josip Rodin. 이 문서는 GNU General Public License 버전 2 이하에 따라 만들었다. 이 문서는 다음 두 문서를 기본으로 만들었다: Making a Debian Package (AKA the Debmake Manual), copyright (C) 1997 Jaldhar Vyas . The New-Maintainer's Debian Packaging Howto, copyright (C) 1997 Will Lowe . 이 문서는 Josip Rodin의 Debian New Maintainer's Guide 1.0(2000/1/25)를 류창우가 번역한 문서입니다(2000/8/20). 이를 1.2(2002/4/6)에 맞춰 양유성이 다시 수정하고 더해서 번역한 문서 입니다(2004/10/3). ------------------------------------------------------------------------------- 차례 ---- 1. "제대로 된 방법으로" 시작하기 1.1. 개발작업에 필요한 프로그램 1.2. 그 외의 정보 2. 첫 단계 2.1. 프로그램 고르기 2.2. 프로그램 가져와서 써 보기 2.3. 패키지 이름과 버전 2.4. "데비안 패키징" 시작하기 3. 소스 코드 수정하기 3.1. 서브 디렉토리에 설치 3.2. 라이브러리의 차이 4. debian/ 아래 필요한 것들 4.1. `control' 파일 4.2. `copyright' 파일 4.3. `changelog' 파일 4.4. `rules' 파일 5. debian/ 디렉토리에 있는 그 밖의 파일 5.1. README.debian 5.2. conffiles 5.3. dirs 5.4. manpage.1.ex 5.5. menu.ex 5.6. watch.ex 5.7. ex.doc-base 5.8. postinst.ex, preinst.ex, postrm.ex, prerm.ex 6. 패키지 빌드 6.1. 패키지 빌드 7. 패키지에 오류가 있는지 검사하기 8. 패키지 업로드하기 9. 패키지 갱신 9.1. 새로운 데비안 리비전 9.2. 새로운 상위소스 릴리즈 9.3. 패키지 업그레이드 확인하기 10. 도움을 얻을 수 있는 곳 ------------------------------------------------------------------------------- 1. "제대로 된 방법으로" 시작하기 -------------------------------- 이 문서는 평범한 데비안 사용자에게 평범한 용어로 데비안 GNU/Linux 패키지를 만드는 방법을 (개발자가 되고 싶어하는) 설명하며, 실제 예제를 이용해 이 방법을 설명할 것이다. 옛날에 한 로마사람이 이렇게 말하길, _Longum iter est per preaecepta, breve et efficax per exempla!_ (규칙은 멀고 험한 길이지만, 예제와 함께 있으면 짧고 효율적이다!). 데비안을 이렇게 최상의 위치를 차지하는 리눅스 배포판으로 만든 한 가지 이유는 데비안의 패키징 시스템이다. 이미 엄청나게 많은 양의 소프트웨어가 이미 데비안 형식으로 만들어져 있긴 하지만, 어떤 경우에는 이렇게 데비안 패키지로 만들어 있지 않은 소프트웨어를 설치해야 할 경우도 있다. 이런 경우 직접 패키지를 만드는 방법을 알고 싶어할 것이고 어쩌면 이 작업이 매우 어려운 일이라고 생각할 지도 모르겠다. 음, 당신이 리눅스에 진짜 초보자라면 이 일은 어렵다. 하지만 당신이 정말 그렇게 풋내기라면, 지금 이 문서를 읽고 있지는 않을 것이다. :-) 유닉스 프로그래밍에 대해 약간 알아야 하지만, 절대 유닉스 프로그래밍의 도사일 필요는 없다. 확실한 것은: 여러분이 필요한 패키지를 적절히 만들고 관리하는 일이다. 작업을 할 우리 시스템을 위해서 실수를 하지 말아야하고 그러기 위해 관리자들은 기술적으로 뛰어나고 부지런해야 한다. 이 문서는 약간 관계없을 수 있지만 하나 하나 차근차근 설명해 나가면서 여러분이 첫 패키지를 만드는데 도움을 주고 패키지를 계속 관리해 나가면서 나중에 하게될 다른 패키지를 만들고 관리하는데 도움을 줄 것이다. 이 문서의 최신 버전은 http://www.debian.org/doc/maint-guide에서 온라인으로 읽을 수 있고, '`maint-guide-ko'' 패키지에 들어 있다. 1.1. 개발작업에 필요한 프로그램 ------------------------------- 시작하기 전에, 데비안 패키지 개발에 필요한 패키지들이 설치되어 있어야 한다. 다음의 패키지 목록에는 `essential'이나 `required'라고 되어 있는 패키지는 포함하지 않았다 (`essential'이나 `required' 패키지는 이미 설치되어 있다고 가정한다). 이 문서의 수정본은 데비안 2.2 ('potato')와 3.0 ('woody')에 있는 패키지에 알맞게 업데이트 되었다. 다음 패키지들은 데비안을 표준으로 설치했을 때 포함되어 있을 테니, 아마도 이미 설치되어 있을 것이다. 어쨌든 `dpkg -s 패키지'로 패키지가 설치되어 있는지 확인해 보자 * `dpkg-dev' - 이 패키지는 패키지를 풀고 빌드하며 데비안 소스패키지를 업로드하는데 필요하다. (dpkg-source(1) 참고) * `file' - 이 손쉬운 프로그램은 이 파일이 어떤형태 파일인지 알려준다. (file(1) 참고) * _binutils_ - 오브젝트 파일을 어셈블하고 링크할 때 쓰이는 프로그램 - 프로그램을 만드는 도구들이다. (`info binutil' 참고) * _cpp_ - C 전처리기. (cpp(1) 참고) * _cpio_ - tar나 zip과 같은 압축 프로그램이다. (cpio(1) 참고) * _gcc_ - GNU C 컴파일러. 대부분의 리눅스 프로그램은 C로 만들어졌다. (gcc(1) 참고) 이 패키지는 오브젝트 파일을 모으고 링크시키는 `binutils' 과 같은 몇몇 프로그램을 "끌어 온다"(`binutils-doc' 패키지 에 있는 `info binutils'를 참고). 그리고 C 전처리기인 `cpp' 도 "가지고 온다"(cpp(1)) 참고) * `g++' - GNU C++ 컴파일러로 C++로 만든 프로그램이면 필요하다.(g++(1) 참고) * _libc6-dev_ - gcc가 링크할 때 필요한 C 라이브러리와 오브젝트 파일을 만들 때 필요한 헤더 파일. 몇몇 프로그램은 libc5를 추천/사용할 수도 있지만, 새로운 버전(libc6)을 사용하는 사용하는 것이 좋다. ( `glibc-doc' 패키지에 들어있는 `info libc' 참고) * _make_ - 프로그램을 만드는 작업은 보통 여러 단계가 필요하다. 같은 명령어를 계속해서 다시 타이프하는 대신에, `메이크파일'을 만들어서 make를 사용하면 이 과정을 자동화할 수 있다. (`info make' 참고) * _patch_ - 매우 유용한 프로그램으로, 원 파일과 패치된 파일의 차이점들이 열거되어 있는 파일(diff 프로그램으로 만든다)을 입력으로 받아들여 원 파일에 적용하면 패치된 버전을 만들어 낸다. (patch(1) 참고) * _perl5_ - 오늘날 유닉스 계열의 시스템에서 가장 많이 사용되는 인터프리터 스크립트 언어의 하나로, "유닉스의 스위스 군용칼"로 불리우기도 한다. (perl(1) 참고) 다음 패키지도 설치해야할 것이다: * `autoconf'와 `automake' - 많은 새로운 프로그램들은 설정 스크립트와 Makefiles을 쓰게 되는데 autoconf와 automake를 통해서 미리 도움을 받을 수 있다.(`info autoconf`, `info automake` 참고) * _dh-make_와 _debhelper_ - dh-make는 뒤에서 나올 예제 패키지를 만들 때 처음 그 골격을 만들 때 필요하다. 이 프로그램이 패키지를 만들 때 debhelper에 있는 도구들을 쓴다. debhelper 프로그램들은 패키지를 만들 때 꼭 필요한 프로그램은 아니지만, 새로운 관리자들에게는 _강력하게_ 추천한다. 이 도구를 쓰는 편이 쓰지 않는 편보다 훨씬 시작하기도 쉽고, 나중에 관리하기도 쉽다. (dh_make(1), debhelper(1), /usr/share/doc/debhelper/README 참고) * _devscripts_ - 이 패키지에는 관리자들에게 쓸모있는 멋진 스크립트들이 들어 있다. 하지만, 이것도 패키지를 만드는 데 꼭 필요한 것은 아니다. (/usr/share/doc/devscripts/README.debian.gz 참고) * _fakeroot_ - 빌드과정에서 필요한 `root가 되는' 일을 가상적으로 해 준다. (fakeroot(1) 참고) * `gnupg' - 여러분이 전자 _서명_을 도와주는 패키지이다. 다른 사람에게 패키지를 배포할 때 꼭 필요하며 데비안 배포본에 패키지 작업 을 할 때 반드시 이 패키지를 써야한다.(gpg(1) 참고) * `g77' - GNU 포트란 77 컴파일러인데 포트란으로 프로그램을 만들었다면 필요하다.(g77(1)) * `gpc' - GNU 파스칼 컴파일러인데 파스칼로 프로그램을 짰다면 필요하다. 파스칼 컴파일 작업에 유용한 Free 파스칼 컴파일러 `fp-compiler'도 있다. (gpc(1), ppc386(1)) * `xutils' - 몇몇 프로그램은 X11용으로 나와서 이 프로그램을 써서 매크로 함수모음에서 Makefiles를 만들 수 있게 해준다. (imake(1), xmkmf(1)) * _lintian_ - 패키지를 만든 다음에 흔히 범하는 실수가 있으면 알려주고 문제점을 설명해 준다. (lintian(1), /usr/share/doc/lintian/lintian.html/index.html 참고) 마지막으로, doc 섹션에 다음의 _매우 중요한_ 패키지들이 있다: * _debian-policy_ - 이 안에는 아카이브의 구조와 내용, 몇몇 운영체제 설계 이슈, 파일시스템 구조 표준(Filesystem Hierachy Standard)이 들어 있고 무엇보다 (여러분에게) 가장 중요한 점은 배포판에 포함될 각 패키지가 지켜야 할 필수 조건들에 대해 설명한다는 것이다. (/usr/share/doc/debian-policy/policy.html/index.html 참고) * _developers-reference_ - 패키징의 기술적인 점을 제외한 모든 문제를 다룬다. 아카이브의 구조, 어떻게 이름을 바꾸고, 주인없는 패키지로 만들고, 패키지를 떠맡고, 어떻게 NMU를 하고, 어떻게 버그를 관리하고, 언제 어디에 업로드를 해야 한다는 것 등이다. (/usr/share/doc/developers-reference/developers-reference.html/index.html 참고) 위에 주어진 짤막짤막한 설명은 각 패키지가 하는 일이 무엇이지 소개하는 것 뿐이다. 계속 나아가기 전에 각 프로그램의 문서를, 최소한 기본적인 사용법이라도 읽어보기 바란다. 지금은 문서를 읽는 일이 매우 부담스럽겠지만, 나중에 가면 문서를 읽어 보았다는 사실에 _매우_ 다행스럽게 여길 것이다. 주: _debmake_ 패키지에는 dh-make와 비슷한 기능을 하는 프로그램이 들어 있다. 하지만 debmake의 사용법은 이 문서에서 설명되지 _않는다_. 자세한 정보는 Debmake 매뉴얼 (http://www.debian.org/~jaldhar/) 참고. 1.2. 그 외의 정보 ----------------- 두 가지 종류의 패키지를 만들 수 있다. 한가지는 소스 패키지이고, 다른 하나는 이진 패키지이다. 소스 패키지에는 프로그램으로 컴파일할 수 있는 코드가 들어 있다. 이진 패키지에는 최종 프로그램이 들어간다. 프로그램의 소스와 프로그램의 소스 패키지라는 식으로 용어를 섞어 쓰지 말아야 한다! 이 용어에 대해 자세한 사항을 알고 싶으면 다른 매뉴얼을 읽어 보기 바란다. 데비안에서는 `관리자(maintainer)'라는 용어가 패키지를 만드는 사람을 가리킨다. 그리고 `상위 개발자(upstream author)'라는 말이 해당 프로그램을 만든 사람을 가리키고, `상위 관리자(upstream maintainer)'가 데비안과 관계없이 프로그램을 현재 관리하고 있는 사람을 가리킨다. 보통 개발자와 상위 관리자는 같은 사람이다 - 어떤 경우에는 관리자까지 같은 사람일 수도 있다. 만약 여러분이 프로그램을 만들고, 그 프로그램을 데비안에 포함시키려고 한다면 주저하지 말고 관리자가 되기 위한 신청을 하기 바란다. 패키지를 만든 다음에 (혹은 만드는 중에), 프로그램을 다음 배포본에 집어 넣고 싶을 경우에 (또 프로그램이 쓸모있는 경우, 물론 쓸모 있을 것이다) 공식 데비안 관리자가 되어야 한다. 그 과정은 Developer's Reference에 설명되어 있다. 이 문서를 읽기 바란다. ------------------------------------------------------------------------------- 2. 첫 단계 ---------- 개발자 코너 (http://www.debian.org/devel/) 웹페이지에 들어 있는 문서는, 새로운 관리자가 확실히 어디서부터 어떻게 작업을 시작할지 알려주지 않는다. 하지만 이 문서에서는 (처음에는 별 상관없는) 매 단계 하나하나를 설명할 것이고, 독자가 첫번째 패키지를 만들 수 있도록 도와주고, 독자는 그 패키지의 다음 릴리즈를 만들고 나중에 다른 패키지를 만들 면서 경험을 얻을 수 있을 것이다. 2.1. 프로그램 고르기 -------------------- 아마도 여러분은 만들고자 하는 패키지를 벌써 골랐을 것이지만, 초보자를 위해 몇가지 짚고 넘어갈 사실을 써 놓았다: * 그 패키지가 이미 배포판 안에 있는지 확인한다. `stable' 배포판을 사용한다면, package search page (http://www.debian.org/distrib/packages.html)에 가 보는 것이 가장 좋다. _현재의_ `unstable' 배포판을 사용한다면 다음 명령어로 확인한다: dpkg -s program dpkg -l '*program*' 이미 패키지가 있다면 그냥 설치해라! :-) 만일 그 패키지가 고아가 됐다면 -- 그 패키지 메인테이너가 "데비안 QA 모임"이라면 그 패키지를 가져올 수 있다. 고아 패키지목록 (http://www.debian.org/devel/wnpp/orphaned) 을 살표보고 입양할 패키지목록 (http://www.debian.org/devel/wnpp/rfa_bypackage) 을 잘 살펴서 패키지가 도움이 필요한지 안한지 확인해야한다. 만일 패키지를 입양할 수 있다면 `apt-get source packagename')를 해서 소스를 받고 테스트를 해봐라. 이 문서는 불행히 패키지 입양까지 친절하게 설명해주고 있지 않다. 고맙게도 이 패키지 안에는 이미 설정파일들이 잘 되어 있기 때문에 그리 어럽지 않게 패키지가 잘 돌아가게 할 수 있을 것이다. 그래도 아래에 나와있는 내용을 꼼꼼이 읽어두면 많은 도움을 받을 것이다. 패키지가 새롭다면 데비안에 있는지 우선 찾아봐야한다. 다음 과정을 따라하면 된다: * 다른 누군가가 이미 패키지를 만들고 있는지 the list of packages being worked on (http://www.de.debian.org/devel/wnpp/being_packaged). 에서 확인하라. 이미 다른 누군가가 만들고 있으면 그들에게 이야기를 해보고 그게 안된다면 누구도 관리하지 않는 새로운 패키지를 찾아본다. * 프로그램은 _반드시_ 라이센스가 있어야 한다. 가능하다면 Debian Free Software Guidelines (http://www.debian.org/social_contract.html#guidelines)에 맞는 자유로운 라이센스여야 한다. DFSG에 맞지 않는다고 해도 데비안의 `contrib'이나 `non-free' 섹션에 포함될 수 있다. 어느 섹션에 들어갈지 불확실하다면, 에 물어본다. * 프로그램은 절대 setuid root, 혹은 그 이상으로 실행되어서는 _안 된다_. setuid나 setgid인 프로그램이 없어야 한다. * 프로그램은 데몬이어서는 안되고, */sbin 디렉토리에 들어가는 프로그램이어서도 안 된다. * 프로그램은 이진 실행 프로그램이다. 아직 라이브러리는 시도해 보지 않는다. * 잘 문서화되어 있어야 한다. 최소한 (모든 사람이) 이해할 수 있어야 한다. * 프로그램의 개발자와 연락해서 개발자가 패키징에 동의하는지 확인한다. 프로그램에 관계된 문제가 발생했을 경우에 개발자와 연락할 수 있도록 하는 건 매우 중요한 일이므로, 관리되고 있지 않은 소프트웨어를 패키징하려고 노력하지 말라. * 그리고 마지막이지만 중요한 것으로 그 프로그램이 제대로 동작하는지 알아야 하고, 어느정도 그 프로그램을 사용해 봤어야 한다. 물론 위의 사항들은 안전을 위한 조치일 뿐이며, setuid 데몬에서 뭘 잘못했을 경우, 분노한 사용자들로부터 여러분을 보호하기 위한 조치이다... 패키징에 좀 더 많은 경험을 쌓으면, 그러한 패키지도 만들 수 있을 것이다. 하지만, 가장 경험많은 개발자라 할지라도 의심스러울 경우에는 debian-devel 메일링 리스트에 물어본다. 그리고 그 곳의 사람들이 기쁜 마음으로 도움을 줄 것이다. 여기에 대한 더 많이 알고 싶으면, Developer's Reference를 참고하기 바란다. 2.2. 프로그램 가져와서 써 보기 ------------------------------ 이제 첫번째로 할 일은 원 패키지를 찾아서 내려받는 일이다. 여러분은 이미 개발자의 홈페이지에서 가져온 소스 파일이 있다고 가정한다. 자유 리눅스 프로그램의 소스는 보통 tar/gzip 형식이고, .tar.gz이나 .tgz 확장자가 붙어 있고, 그 안에 `프로그램-버전'이라는 서브 디렉토리가 있어서 그 안에 모든 소스가 들어 있다. 여러분의 프로그램 소스가 다른 종류의 압축으로 되어 있다면 (예를 들어, 파일이름이 `.Z'나 `.zip'으로 끝난다면), 적당한 도구로 그 파일을 푼다. 올바르게 푸는 방법을 모르겠으면 debian-mentors에 물어본다 (힌트: `file 아카이브명.확장자'을 실행한다). 예제로 나는 `gentoo'라는 이름의 프로그램을 사용할 것이다. gentoo는 GTK+를 사용하는 X11용 파일 관리자이다. 이 프로그램은 이미 패키징되어 있고, 현재 이 패키지는 이 문서를 처음 작성할 당시의 버전과 비교하면 많은 부분이 달라져 있음에 유의한다. 홈 디렉토리 밑에 `debian'이나 `deb' 등 적당한 이름의 디렉토리를 만든다 (이 경우에는 ~/gentoo/ 가 좋을 것이다). 그 안에 내려 받은 압축 파일을 놓고, 압축을 푼다 (`tar xzf gentoo-0.9.12.tar.gz'으로). 여기서 애러가 없어야 한다. 무시할 수 있는 애러라도 다른 사람들의 시스템에서 압축을 풀 때 문제가 발생할 수 있다. 그 사람들의 시스템에서는 그 애러가 무시할 수 없을 수 있기 때문이다. 이제 새로운 `gentoo-0.9.12'라는 서브 디렉토리가 생긴다. 그 디렉토리로 들어가서 거기에 주어진 문서를 _완전히_ 읽는다. 그 문서는 보통 README*, INSTALL*, *.lsm, 혹은 *.html이라는 파일 안에 들어 있다. 그 파일 안에 어떻게 프로그램을 컴파일하고 설치할 것인지에 관한 안내가 들어 있을 것이다. (보통 /usr/local/bin 디렉토리에 설치한다고 가정할 것이다; 패키징시에는 그렇게 하지 않는다. 자세한 것은 뒤의 3.1, `서브 디렉토리에 설치'참고.) 프로그램을 컴파일하고 설치하는 과정은 프로그램마다 다르지만, 최근의 프로그램은 대부분 `configure' 스크립트가 있어서 여러분의 시스템에 맞게 소스를 설정하고, 시스템이 소스를 컴파일할 수 있는 지를 검사해 준다. (`./configure'로) 설정을 한 후에, 프로그램은 보통 `make'로 컴파일된다. 어떤 경우엔 `make check'가 지원되고, 이 명령어는 거기에 포함된 자체 검사를 실행하게 된다. 목표 디렉토리로 설치하는 명령은 보통 `make install'이다. 이제 프로그램을 컴파일하고 실행해 보면서, 이 프로그램이 문제 없이 동작하고 설치나 실행 과정에서 충돌이 생기지 않는지 확인한다. 또 설치된 파일들을 지우려면 보통 `make uninstall'을 타이프한다. 그리고 빌드 디렉토리를 지우고 새롭게 빌드하려면 `make clean'(혹은 더 좋은 `make distclean')을 타이프한다. 2.3. 패키지 이름과 버전 ----------------------- 완전히 깨끗한 (빌드하기 전 원래 모습의) 소스 디렉토리에서 시작해야 한다. 간단히 새로 압축을 푼 소스에서 시작할 수도 있다. 프로그램이 제대로 빌드되었다면, 프로그램의 원래 이름을 소문자로 바꾼다 (이미 소문자가 아니라면). 그리고 소스 디렉토리의 이름을 <패키지명>-<버전>로 바꾼다. 프로그램 이름이 한 단어 이상으로 구성되어 있다면, 한 단어로 바꾸거나 줄임말을 쓴다. 예를 들어, "John's little editor for X" 패키지는 johnledx, jle4x 등의 이름으로 바뀐다. 이름은 여러분이 결정하기 나름으로 어느 정도 적당한 (20자 정도) 길이보다 짧으면 된다. 또 프로그램의 정확한 버전을 확인한다. 이 버전은 패키지 버전에 포함된다. 해당 소프트웨어가 X.Y.Z같이 버전이 매겨져 있지 않고, 릴리즈 날짜만 매겨져 있는 경우에는 그 날짜를 버전으로 사용하되, "0.0."을 앞에 붙인다 (어느 날 갑자기 상위 관리자가 버전을 1.0과 같이 붙일 경우를 대비해서). 날짜가 1998년 12월 19일이라면 0.0.19981219라고 버전을 쓰면 될 것이다. 어떤 프로그램은 아예 버전이 없는 경우도 있는데, 이 경우는 상위 관리자에게 연락해서 각 버전을 구분하는 어떤 방법이 있는지 확인한다. 2.4. "데비안 패키징" 시작하기 ----------------------------- 프로그램 소스 디렉토리 안에 들어간 다음, 다음을 실행한다: dh_make -e 여러분의.관리자@주소 -f ../gentoo-0.9.12.tar.gz 당연히 "여러분의.관리자@주소"는 여러분의 전자우편 주소를 쓴다. 이 주소는 changelog와 그 밖의 파일들에 포함된다. 그 다음은 원 소스 압축 파일의 이름이다. 자세한 것은 dh_make(1) 참고. 몇가지 정보가 나타날 것이다. dh_make는 만들고자 하는 패키지가 어떤 종류인지 물어볼 것이다. gentoo는 한개의 이진 패키지이다 - 이 패키지 안에는 한개의 바이너리만 들어 있으므로, 한개의 .deb 파일만 필요하다 - 그러므로 우리는 첫번째 `s' 키를 누르고 화면의 저보를 확인한 다음 <엔터>를 누른다. 새로운 관리자인 여러분은 앞에서 설명한 대로, 여러개의 바이너리 패키지나, 라이브러리 패키지를 만들지 않는 것이 좋다. 사실 이러한 패키지를 만드는 것도 그리 어려운 것은 아니지만, 좀 더 지식이 필요하므로 여기서는 설명하지 않는다. dh_make를 _오직 한번만_ 실행해야 한다는 것에 주의하자. dh_make는 이미 "데비안화 되어 있는(debianized)" 디렉토리에서 똑같이 여러번 실행할 경우 제대로 동작하지 않을 것이다. 여기서 앞으로 새로운 버전의 패키지 개정판을 릴리즈할 때는 dh_make가 아닌 다른 방법을 사용할 것이라는 사실을 알아 챌 수 있다. 이 방법에 관해서는 이 문서의 뒷 부분의 9, `패키지 갱신' 참고. ------------------------------------------------------------------------------- 3. 소스 코드 수정하기 --------------------- 보통의 경우, 프로그램은 /usr/local 디렉토리 밑에 프로그램을 설치하게 된다. 하지만, 데비안 패키지는 이 디렉토리를 사용하면 안 된다. /usr/local 디렉토리은 시스템 관리자의 (혹은 사용자의) 개인적인 용도로 쓰이기 때문이다. 즉, 메이크파일부터 시작해서 프로그램의 빌드 시스템 내부를 살펴봐야 한다. 메이크파일은 make(1)가 프로그램을 빌드하는 과정을 자동화할 때 쓰이는 스크립트이다. 메이크파일에 관해 자세한 사항은 4.4, ``rules' 파일'를 참고한다. 메이크파일에 대한 자세한 정보는 4.4, ``rules' 파일' 참고. 여러분의 프로그램이 GNU automake(1)나 autoconf(1)를 쓰는지 확인한다. automake의 경우 소스 안에 Makefile.am 파일이 들어 있고, autoconf의 경우 Makefile.in 파일이 들어 있다. 이 경우에 이들 Makefile.am 혹은 Makefile.in 파일을 수정해야 할 수도 있다. automake는 Makefile.am 파일의 정보를 이용해 Makefile.in 파일을 만들고, 마찬가지로 ./configure를 실행할 때마다 Makefile.in의 정보를 읽어서 Makefile을 만들어 내기 때문이다. Makefile.am 파일을 수정하려면 automake에 관한 지식이 필요한데, 여기에 관해서는 automake info 매뉴얼에서 읽을 수 있다. 반면, Makefile.in 파일 수정은 Makefile 수정과 거의 동일하다. 단지 변수에만 유의한다. @CFLAGS@나 @LN_S@와 같이 `@'로 둘러쌓인 문자열이 변수이고, 이 부분은 ./configure를 실행할 때마다 해당 변수의 값으로 바뀐다. 이 문서의 지면상 사람들이 종종 맞닥드리는 문제점들에 대해 어떻게 수정해야 하는지 _전부_ 안내하지는 못한다는 점을 기억해 둔다. 3.1. 서브 디렉토리에 설치 ------------------------- 대부분의 프로그램들은 여러분의 시스템 구조에 맞게 설치하는 방법이 있어서, 해당 실행 파일을 $PATH에 포함시킬 수 있다. 여기에 관해서는 해당 문서와 매뉴얼을 살펴본다. 해당 프로그램이 제대로 이 기능을 하는 지 확인한다. 이렇게 되면 이미 설치한 다른 것들과 같이 설치 될 것이고 이렇게 되면 패키지 도구가 어떤 파일이 여러분이 패키지에 들어 있는지 아닌지 확인하지 못한다. 따라서 이 일을 할 필요가 있다: 패키징해주는 도구가 .deb을 만드는 임시 서브디렉토리에 프로그램을 설지한다. 이 디렉토리에 있는 모든 것은 패키지를 설치했을 때, 사용자 시스템에 설치될 것이고 단지 다른 점은 dpkg가 루트 디렉토리에 파일들을 설치한다는 점이다. 이 임시파일은 debian 디렉토리 안에 생기고 이는 `debian/packagename'이다. 기본적으로, 프로그램이 debian/tmp에 설치되긴 하지만, 루트 디렉토리에 설치되었을 때 제대로 동작하도록 설치해야 한다. 즉, .deb 패키지로 설치했을 때 제대로 동작해야 한다. GNU autoconf를 이용하는 프로그램의 경우에는 dh_make가 자동으로 여기에 필요한 해당 명령어들을 만들어 주기 때문에 매우 쉽다. 그러므로 이 `gentoo' 예제의 경우에는 이 부분을 읽지 않고 넘어가도 좋다. 그러나 그 외의 프로그램은 경우에 따라 Makefile을 수정해야 한다. 다음은 gentoo의 Makefile에서 관련된 부분이다. # Where to put binary on 'make install'? BIN = /usr/bin # Where to put icons on 'make install'? ICONS = /usr/share/gentoo 그런데 왜 하필이면 다른 디렉토리도 아니고, 이 디렉토리인가? 데비안 패키지는 `/usr/local'에 설치되지 않고 여기는 단지 시스템 관리자만 쓸 수 있다. 데비안에 있는 이러한 파일들은 모두 `/usr'에 있다. 바이너리와 아이콘, 문서가 있는 위치는 파일시스템 구조 표준(/usr/share/doc/debian-policy/fhs/)에 지정되어 있다. 이 문서를 잘보고 어디에 여러분 패키지가 있어야할지 확인하기 바란다. 자 이제 여러분은 바이너리를 /usr/local/bin이 아닌 /usr/bin에 설치 해야한다. 그리고 맨페이지는 /usr/local/man/man1가 아닌 /usr/share/man/man1 에 나와야한다. gentoo에 대한 매뉴얼 페이지가 있는지 확인하고 만일 없다면 만들고나서 /usr/share/man/man1에 설치하면 된다. 몇몇 프로그램들은 이런 경로를 정의하는 makefile 변수를 쓰지 않는 경우 가 있다. 결국 C 소스를 수정해서 이를 수정하고 제대로 작동하게 만들어야 한다. 그럼 어떻게 찾아야하나? 다음과 같은 명령을 쓸 수 있다: grep -nr -e 'usr/local/lib' --include='*.[c|h]' . grep 프로그램은 usr/local/lib이 나타난 파일의 이름과 그 파일의 몇번째 줄에서 usr/local/lib이 나타났는지 알려준다. 여기를 편집하고 /usr/local/*를 usr/*로 바꾼다. 코드 나머지 부분에도 이 부분이 헷갈리지 않게 조심한다. 이렇게 한 후에 install 타겟을 찾고 (`install:'으로 시작하는 줄을 찾는다), 위에서 수정한 변수 이외에 /usr/local/... 디렉토리의 이름을 직접 언급하는 부분이 있으면 바꾼다. gentoo의 경우에는 그런 경우가 있었고, 좀 보기 좋게 고쳐줘야 했다. 고치기 전의 gentoo의 install 타겟은 다음과 같았다: # ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo install ./gentoo $(BIN) install icons $(ICONS) install gentoorc-example $(HOME)/.gentoorc 고친 후에는 다음과 같다: # ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc 여기서 모든 규칙앞에 `install -d'이 있다는 것을 확인할 수 있다. 보통 /usr/local/bin과 다른 디렉토리가 이미 있어서 거기에서 `make install' 이 돌아가기 때문에 원래 Makefile에는 이 부분이 없다. 없는 디렉토리에 설 치하려고 하기 때문에 이런 디렉토리를 하나 하나 만들어야한다. 추가 문서에 대한 정보는 여기서 할 수 있다: install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html 주의 깊게 보면 `install:'줄에서 `gentoo'를 `gentoo-target'으로 바꾸었다는 사실을 알아 챌 것이다. 이런 걸 버그 수정이라고 한다 :-) 이렇게 데비안과는 특별히 관계없는 문제점을 고쳤을 경우에는, 다음 프로그램 버전에 포함될 수 있도록 상위 관리자에게 꼭 알려주도록 한다. debian/* 파일들은 보낼 필요 없고, 그 외의 패치를 보내야 한다. 패치를 보내기 전에 그리고 그 패치가 데비안 혹은 리눅스(심지어는 유닉스!)에만 특별히 관계된 사항이 아니라는 걸 확인하고 상위 관리자에게 보낸다. 3.2. 라이브러리의 차이 ---------------------- 또 한가지 흔히 만나는 문제가 있다: 라이브러리는 각 플랫폼마다 다르다. 예를 들어 메이크파일에서 데비안에 없는, 심지어는 리눅스에 없는 라이브러리와 링크하려고 하는 경우도 있다. 이 경우에 데비안에 들어 있는, 같은 기능을 하는 라이브러리로 바꿔야 한다. 가장 좋은 방법은 그 줄을 주석처리하는 것이다. 지우지 않는 건 다른 플랫폼에서 컴파일하는 사람도 있을 것이고, 그 사람에게 문제의 원인을 알려주는 힌트를 남겨주기 위해서이다. 예를 들어, 프로그램의 Makefile(혹은 Makfile.in)에 다음과 같이 쓰여 있으면 (그리고 프로그램이 컴파일되지 않으면): LIBS = -lcurses -lsomething -lsomethingelse 다음과 같이 바꾼다. 이제 컴파일이 될 것이다: LIBS = -lncurses -lsomething -lsomethingelse (이 예가 가장 좋은 예가 아니다. libncurses 패키지가 현재는 libncurses.so에 심볼릭 링크가 걸려있지만 저자는 나쁘다고 생각하지 않을 것이다. 좋은 제안 있으면 알려주기 바란다. :-) ------------------------------------------------------------------------------- 4. debian/ 아래 필요한 것들 --------------------------- 프로그램의 주 디렉토리 아래에 `debian'이라는 새로운 서브 디렉토리가 만들어져 있다. 이 디렉토리 안에는 여러개의 파일들이 들어 있다. 이제 패키지를 제대로 조정하려면 차례로 이 파일들을 편집한다. 이 중에 가장 중요한 파일은 `control', `changelog', `copyright', 그리고 `rules'이다. 이 파일들은 모든 패키지에 필요하다. 4.1. `control' 파일 ------------------- 이 파일 안에는 dpkg나 dselect에서 패키지를 관리할 때 필요한 여러가지 값들이 들어 있다. 다음은 dh_make가 자동으로 만들어 주는 control 파일이다: 1 Source: gentoo 2. Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <최대 60글자의 설명을 쓴다> 12 <긴 설명을 쓴다. 줄 앞에 공백으로 들여 쓴다> (줄 번호를 앞에 붙였다.) 1-6줄은 소스 패키지를 위한 컨트롤 정보이다. 첫번째 줄은 소스 패키지의 이름이다. 첫번째 줄은 소스패키지 이름이다. 두번째 줄은 소스패키지가 들어갈 배포본 섹션을 뜻한다. 이미 알고 있을지도 모르지만, 데비안은 여러개의 섹션으로 나누어져 있다: main (자유 소프트웨어), non-free (자유 소프트웨어가 아닌 것들) 그리고 contrib (자유롭지 않은 소프트웨어에 의존하는 자유 소프트웨어). 이 아래에 이 패키지가 어떤 종류인가를 간단히 설명하는 서브섹션이 있다. 관리 전용 프로그램은 `admin', 기본적인 도구는 `base', 프로그래머의 도구는 `devel', 문서는 `doc', 라이브러리는 `libs', 이메일 읽기 프로그램 및 데몬은 `mail', 네트워크 프로그램과 데몬은 `net', X11에 관계된 프로그램은 `x11', 그 외에도 많이 있다. 그러면 unknown을 x11로 바꾸면 된다.("main/" 이란 부분은 생략할 수 있다.) 세번째 줄은 사용자가 이 패키지를 설치하는 일이 얼마나 중요한지를 나타낸다. Section과 Priority는 패키지를 정렬하고, 기본 패키지를 선택하는 용도로 `dselect'에서만 사용된다. 한번 패키지를 업로드하게 되면 아카이브 메인테이너가 이 두 부분을 덮어 쓰게 되고 이 사실은 이메일을 통해서 알려준다. gentoo의 우선순위는 보통이므로, 그대로 "optional"로 남겨둔다. 네번째 줄은 관리자의 이름과 이메일 주소이다. 이 부분은 이메일에 필요한 "To: " 헤더를 포함하는 것을 뜻한다. 왜냐하면 패키지를 업로 드하면 버그 추적 시스템은 버그 이메일을 여러분에게 보낼 것이다. 쉼표와 &, 소괄호 사용을 하지마라. 다섯번째 줄은 패키지를 빌드할 때 필요한 목록을 보여준다. gcc와 make같은 패키지를 뜻하게 되고 자세한 내용은 `build-essential' 를 보면 된다. 몇몇 비표준 컴파일러나 도구가 패키지를 빌드하는데 필요하면 이를 `Build-Depends' 줄을 추가하고, 거기에 필요한 패키지를 쓴다. 다양한 내용을 쉼표로 구별하고 바이너리 호환에 대한 설명을 잘 읽고 이부분에 넣으면 된다. 이 부분에 Build-Depends-Indep, Build-Conflicts와 같은 것이 들어갈 수 있다. 다른 컴퓨터 플랫폼에서도 돌아가게 바이너리 패키지를 빌드하기 위해 소프트웨어를 자동으로 빌드하는데 이 부분을 쓸 수 있다. 빌드 의존에 대해서 자세한 내용을 알고 싶으면 정책 매뉴얼를 보고 다른 플랫폼과 포팅에 대해서는 데비안 개발 참고서를 보면된다. 여기에 여러분 패키지를 빌드할때 어떤 패키지가 필요한지 할려주는 코드가 있다: strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package doesn't use autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done 여섯번째 줄은 이 패키지가 따라야할 데비안 정책 표준이고 패키지를 만들기 전에 반드시 읽어보길 바란다. 여덟번째 줄은 바이너리 패키지 이름이고 이는 보통 소스 패키지와 같다. 아지만 꼭 그럴 이유는 없다. 아홉번째 줄은 이 이진 패키지가 컴파일될 수 있는 CPU 아키텍처를 쓴다. 우리는 이 필드를 any라고 남겨놓고 dpkg-gencontrol(1) 프로그램이 알아서 컴파일된 기계에 맞는 값을 집어 넣도록 한다(패키지 포팅에 대한 설명은 Developer's Reference 참고). 만약 여러분의 패키지가 아키텍처에 무관하다면 (예를 들어, 셸 스크립트나 펄 스크립트, 문서일 경우), 이 부분을 "all"로 바꾸고, 뒷 부분의 4.4, ``rules' 파일'에서 "binary-arch" 대신에 "binary-indep" 룰을 이용하는 방법을 살펴본다. 열번째 줄은 데비안 패키징 시스템의 가장 강력한 기능들중 하나이다. 패키지는 여러가지 방법으로 또 다른 패키지들과 관계를 맺을 수 있다. Depends 말고, 패키지간의 관계를 나타내는 필드로는 Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, 그리고 Replaces:가 있다. dpkg, dselect, APT(그리고 APT 프론트엔드)와 같은 패키지 관리 도구는 보통 이 패키지 관계에 따라 동일하게 동작한다. 그렇지 않은 경우가 있는데, 다음에 설명한다. (dpkg(8), dselect(8), + apt(8), aptitude(1)) 각각의 의미는 다음과 같다: * Depends: 의존하는(depends) 패키지가 설치되어 있지 않으면 프로그램을 설치하지 않는다. 어떤 패키지가 없을 경우 이 프로그램이 절대 동작하지 않을 때만 (혹은 심각한 문제를 발생할 경우) Depends를 사용한다. * Recommends: dselect는 추천하는(recommends) 패키지가 설치되어 있지 않으면 이 패키지를 설치하지 않는다. 하지만 dpkg와 apt-get은 추천하는 패키지가 설치되어 있지 않은 경우에도 설치한다. 여러분의 프로그램이 꼭 필요로 하지는 않지만, 대부분의 경우에 필요한 패키지인 경우에만 Recommends를 사용한다. * Suggests: 사용자가 이 프로그램을 설치할 때, dselect는 제안하는(suggests) 패키지를 설치하도록 안내한다. Dpkg와 apt-get는 아무 신경쓰지 않고 설치한다. 꼭 필요한 패키지는 아니지만, 여러분의 프로그램과 함께 멋지게 동작하는 패키지에 대해서 Suggests를 사용한다. * Pre-Depends: Depends보다 더 강력하다. 미리 의존하는(pre-depends) 패키지가 설치되고, _또 제대로 설정되었을 경우에만_ 이 패키지를 설치할 수 있다. Pre-Depends는 삼가해서 사용하고, 꼭 debian-devel 메일링 리스트에서 토의한 다음에 사용한다. 즉: 아예 사용하지 않는다. :-) * Conflicts: 충돌하는(conflicts) 패키지가 삭제되지 않는 한 패키지는 설치되지 않는다. 여러분의 프로그램이 어떤 패키지가 존재할 때 동작하지 않을 경우 (혹은 심각한 문제를 발생시키는 경우) Conflicts를 사용한다. * Provides: 여러개 중에 하나를 선택할 수 있는 패키지를 위해 가상 패키지(virtual package)가 정의되어 있다. 가상 패키지의 리스트는 /usr/share/doc/debian-policy/virtual-package-names-list.text.gz에서 구할 수 있다. Provides는 여러분의 프로그램이 가상 패키지를 제공(provides)하는 경우에 사용한다. * Replaces: 당신의 프로그램이 다른 패키지의 파일들을 대체(replaces)하는 경우, 혹은 그 패키지 전체를 대체(replaces)하는 경우(이 경우에는 COnflicts:와 함께 사용한다)에 사용한다. 여기서 지정된 패키지의 파일들은 여러분의 패키지를 설치하기 전에 삭제된다. 이 필드들은 모두 통일된 문법이 있다. 이 필드에는 패키지 이름들을 쉼표로 구분해서 나열해 놓는다. 패키지 이름은 세로줄 표시 `|' (파이프 표시) 를 이용해서 여러개 중에 하나를 선택하는 식으로 만들 수도 있다. 각 패키지의 특정 버전을 지정할 수도 있다. 각 패키지 이름 다음에 괄호 안에 버전과 함께 그 앞에 버전번호의 관계를 나타내는 다음 관계 기호를 쓴다. 사용할 수 있는 관계는 `<<', `<=', `=', `>=' 그리고 `>>'이다. 각각은 앞 버전, 이전 버전, 정확히 같은 버전, 이후 버전, 그리고 뒤 버전을 나타낸다. Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6) 마지막으로 알려줄 기능은 $(shlibs:Depends)이다. 이 부분은 dh_shlibdeps(1)와 dh_gencontrol(1)에 의해 (나중에 설명) 자동으로 libc6나 xlib6g같은 여러분의 프로그램이 사용하는 동적 라이브러리의 이름으로 바뀐다. 즉, 각 라이브러리를 직접 지정할 필요가 없다. 여기서 Depends: 부분은 그대로 놓아둔다. 그리고 여기에 다른 필요한 `Suggests: file'을 넣어서 gentoo가 file 프로그램/패키지가 주는 기능을 쓸 수 있다. 열한번째 줄은 짤막한 설명이다. 대부분의 사람들은 80 컬럼 화면을 사용하므로 이 부분은 60자 이상되지 않도록 않다. 나는 이 부분을 "fully GUI configurable GTK+ file manager"라고 바꿔 놓을 것이다. 열두번째 줄은 긴 설명이 들어간다. 이 부분은 패키지에 대해 좀 더 자세히 설명하는 한개의 문단이다. 각 줄의 첫번째 열은 공백이어야 한다. 절대로 빈 줄이 들어가서는 안 된다. 빈 줄이 들어가야 할 곳에서는 대신에 .을 쓴다. 또, 이렇게 긴 설명을 끝낸 다음에는 빈 줄을 두개 이상 넣지 않는다. 다음은 수정된 control 파일이다: 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable X file manager using GTK+ 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter). (줄번호는 여기서 넣은 것이다.) 4.2. `copyright' 파일 --------------------- 이 파일에는 해당 패키지의 상위 정보, 저작권과 라이센스 정보가 들어 있다. 이 형식은 데비안 정책에서 정의되지 않았지만, 그 내용은 지정되어 있다 (섹션 12.6). dh_make가 기본적으로 만드는 파일이 있는데, 다음과 같다: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from 5 6 Upstream Author(s): 7 8 Copyright: 9 10 (줄 번호를 앞에 붙였다) 이 파일에 써 넣어야 할 매우 중요한 것은 첫째로 이 패키지를 가져온 위치이고, 또 하나는 실제 저작권 명시와 라이센스이다. GNU GPL 혹은 LGPL, BSD, Artistic 라이센스와 같은 유명한 자유 소프트웨어 라이센스가 아니라면, 완전한 라이센스를 포함해야 한다. 이런 유명한 라이센스의 경우에는 모든 데비안 시스템에 있는 /usr/share/common-licenses/ 디렉토리 밑의 해당 파일을 참고하면 된다. Gentoo의 라이센스는 GNU General Public License이므로 copyright 파일을 다음과 같이 바꿀 것이다: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 12 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in /usr/share/common-licenses/GPL file. 4.3. `changelog' 파일 --------------------- 이 파일은 꼭 필요하다. 이 파일은 정책 문서 4.4j8 "debian/changelog" 에 잘 나와있다. 이 형식은 dpkg에 의해 사용되고 그 밖의 프로그램들이 버전(version), 개정(revision), 배포판 및 이 패키지의 긴급성(urgency)을 알아 내는데 사용한다. 초보자를 위해서도 이 파일은 중요하다. 수정한 모든 사실에 대해 문서화하는 것이 좋다. 여러분의 패키지를 내려받게 될 사람들이 이 파일을 통해 패키지에 해결되지 않은 문제가 있는지 즉각 알아 볼 수 있다. 이 파일은 바이너리 패키지에서 /usr/share/doc/gentoo/changelog.Debian.gz 파일로 저장된다. 다음은 dh_make가 만들어 주는 기본 changelog 파일이다: 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 6 (줄 번호를 앞에 추가했다.) 첫 줄은 패키지 이름, 버전, 배포판, 그리고 긴급성이다. 이름은 소스 패키지의 이름과 같아야 한다. 배포판은 unstable이나 experimental이 되어야 하고, 긴급성은 `low'보다 높은 걸로 바꾸지 않도록 한다. :-) 3-5 줄은 기록하는 부분으로, 여기에 이 패키지 개정판에 바뀐 점을 쓴다. (상위 소스코드의 변화를 쓰지 않는다 - 이 이런 목적의 파일은 상위 개발자가 만들고 /usr/doc/gentoo/changelog.gz 파일로 설치된다.) 맨 위에 별표(`*')로 시작하는 줄 앞에는 빈 줄이 들어가야 한다. 이 작업은 dch(1)로 하거나 텍스트 편집기를 쓸 수 있다. 다음과 같이 해서 이 파일 편집을 마치면 된다. 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 8 (줄번호를 앞에 붙였다.) 9, `패키지 갱신'에 있는 changelog 파일 업데이트 방법을 자세히 읽어볼 필요가 있다. 4.4. `rules' 파일 ----------------- 이제 dpkg-buildpackage(1)가 실제로 패키지를 만들 때 사용할 규칙(rules)을 살펴볼 때다. 사실 이 파일은 또 다른 메이크파일이지만, 상위 소스에 들어 있는 메이크파일과는 다른 파일이다. debian/ 안에 들어 있는 다른 파일들과 달리 이 파일은 실행 가능한 파일이다. `rules' 파일은, 다른 메이크파일과 마찬가지로, 소스를 빌드하는 방법이 쓰여진 여러개의 룰(rule)로 구성되어 있다. 각 룰은 타겟 파일이름 혹은 수행할 동작의 이름(`build:'나 `install:' 따위)가 들어 있다. 실행하고 싶은 룰이 있으면 명령행 인자로 타겟을 넘겨줘야 한다 (예를 들어, `./debian/rules build'나 `./debain/rules install'). 타겟 이름 다음에, 디펜던시(dependency)를 쓴다. 디펜던시는 그 타겟이 의존하는 프로그램이나 파일이다. 그 다음에는 여러개의 명령어가 올 수 있고 (로 시작한다는 점에 주의!), 빈 줄이 발견되면 끝난다. 그 다음에 또 다른 룰이 시작된다. 빈 줄이 여러 개 나타나는 경우나, 해쉬(`#')로 시작하는 주석문은 무시된다. 지금쯤 혼란스러울 것이지만, dh_make가 기본적으로 만들어 주는 `rules' 파일을 들여다 보면 모든 것이 명확해 질 것이다. 더 자세한 사항은 info의 `make' 항목을 읽어본다. dh_make가 만드는 rules 파일에서 중요한 점은, 이 파일은 단지 하나의 예일 뿐이라는 점이다. 간단한 패키지에서는 이 파일이 그대로 동작하겠지만 좀 더 복잡한 경우에는 그렇지 않다. 필요에 따라서 이 파일에 무언가를 추가하거나 지워야 한다. 바꾸지 말아야 할 것은 각 룰의 이름으로, 이 이름들은 정책 문서에에 설명된 각종 빌드도구에서 이용한다. dh_make가 만든 기본으로 나오는 debian/rules 파일이 예이다: 1 #!/usr/bin/make -f 2 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction. 7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure (줄 번호를 앞에 붙였다.) 아마 셸 스크립트나 펄 스크립트를 통해 첫번째 줄과 같은 줄에 익숙해 있을 것이다. 그 줄은 해당 파일이 /usr/bin/make를 통해 실행된다는 사실을 OS에 알려 준다. 12번째 줄에서 19번째 줄은 `build' 룰(및 부수적인 build-stamp룰)로, 이 룰에서는 프로그램을 컴파일하는 프로그램을 실행시킨다. 21-29 줄에 쓰인 `clean' 룰은 필요없는 바이너리나 패키지 빌드 과정에서 자동으로 생성된 파일들을 지운다. 이 룰은 언제나 실행 가능해야 한다 (소스 트리가 이미 clean된 상태에서도!). 그러므로 강제 옵션을 (rm의 경우에는 `-f' 옵션) 이용하거나, 리턴 값을 무시한다 (명령 앞에 `-'를 붙인다). `install' 룰의 인스톨 과정은 31번째 줄에서 시작한다. 기본적으로 프로그램 자체 Makefile의 `install' 룰을 실행하지만, `pwd`/debian/tmp 디렉토리에 추가한다 - gentoo의 Makefile에서 $(DESTDIR)를 설치 디렉토리로 지정한 이유가 바로 이것이다. 주석문이 나타내듯, 41번째 줄의 `binary-indep' 룰은 아키텍처와 무관한 패키지들을 만드는 데 사용된다. 하지만, 우리는 이렇게 빌드할 게 전혀 없기 때문에, 아무것도 쓸 필요가 없다. 여러분의 패키지가 `Architecture all'일 경우에는 이 룰에서 해당 패키지를 빌드하는 명령어를 쓰고, 대신에 다음 룰(`binary-arch')를 비워 놓아야 한다. 다음 45-73 줄의 `binary-arch' 룰에서는 debhelper 패키지에 있는 여러가지 작은 프로그램들을 실행해서 패키지를 데비안 정책에 맞도록 만든다. 이 프로그램들은 dh_로 시작하고, 그 뒤의 이름을 통해 이 작은 프로그램들이 실제로 무슨 일을 하는지 알아 챌 수 있을 것이다. 하지만 추가로 설명을 하면: * dh_testdir(1)는 올바른 디렉토리(소스 디렉토리 맨 위)에서 빌드하는 지 확인한다. * dh_testroot(1)는 root 권한이 있는지 검사한다. root 권한은 binary*, clean 타겟에서 필요하다. * dh_installmanpages(1)는 소스 트리에서 찾을 수 있는 모든 맨 페이지를 설치 위치로 복사한다. (조심, 맨페이지가 아닌 것도 복사할 수 있음.) * dh_strip(1)은 실행 파일과 라이브러리에서 디버깅 헤더를 제거해서 크기를 작게 만든다. * dh_compress(1)는 4 킬로바이트보다 큰 맨 페이지와 문서를 gzip으로 압축한다. * dh_installdeb(1)은 패키지와 관련된 파일들을 debian/tmp 디렉토리로 복사한다. * dh_shlibdeps(1)는 라이브러리와 실행 파일의 동적 라이브러리에 대한 의존성을 검사한다. * dh_gencontrol(1)은 control 파일에 내용을 추가하고 control 파일을 설치한다. * dh_md5sums(1)는 패키지 내의 모든 파일에 대하여 MD5 checksum을 만든다. dh_* 스크립트가 무엇을 하는지, 어떤 옵션이 있는지에 대한 완전한 정보를 알고 싶으면 각각의 맨 페이지를 읽어 보면 된다. 위에 언급되지 않은 많은 dh_* 스크립트가 있고, 어떤 경우에는 그 스크립트가 필요할 수도 있다. 그 스크립트가 필요한 경우 debhelper 문서를 읽어보기 바란다. binary-arch 부분은 필요하지 않은 기능을 주석처리하는 부분이다. gentoo의 경우 testversion, emacsen, pam, init, cron, manpages, info, undocumented, suidregister, makeshlib, 그리고 perl을 주석 처리했다. gentoo는 이 스크립트가 필요 없다. 또 60번째 줄에 `FIXES'를 추가할 것이다. `FIXES'는 상위 changelog 파일이다. 마지막 두 줄은 (설명되지 않은 줄도 마찬가지로), 패키징 매뉴얼에서 읽을 수 있는 바에 따르면 어느 정도 필요한 부분이다. 지금으로써는 특별히 알아야 할 만큼 중요하지 않다. ------------------------------------------------------------------------------- 5. debian/ 디렉토리에 있는 그 밖의 파일 --------------------------------------- debian/ 서브 디렉토리 안에 몇 개의 파일이 더 있다. 대부분은 `.ex'가 뒤에 붙어 있는데, 예제 파일이라는 뜻이다. 그들의 기능을 쓰고 싶으면 관련된 문서를 (정책 매뉴얼) 참조해서, 그 파일이름에서 `.ex'를 뺀 다음 편집하고, `rules' 파일을 수정해서 이용하면 된다. 이 파일 중에서 자주 이용되는 것들은 다음에서 설명한다. 5.1. README.debian ------------------ 그 외에 세부적인 사항이나, 원 패키지와 여러분의 데비안화 된 버전간의 차이점이 이 파일에 쓰여져야 한다. 다음은 dh_make가 만들어 주는 README.debian이다: gentoo for Debian ---------------------- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100 여기에 쓸만한 것이 아무것도 없으므로 - 이 파일을 지워도 좋다. 아니면, 이 파일을 README.Debian으로 바꿔도 된다 :-) 5.2. conffiles -------------- 소프트웨어에 관련하여 가장 황당한 일중 하나는, 업그레이드하면서 전에 있던 파일들이 지워지면서 다시 오랜 시간과 노력을 들여 프로그램을 커스터마이즈해야 하는 경우이다. 데비안에서는 설정 파일들이 무엇인지 표시해 놓고 패키지를 업그레이드할 때 옛날 설정 파일을 유지할 것인가 아닌가를 물어보도록 함으로써 이런 문제를 해결한다. 여러분은 conffiles라는 파일 안에 각 (보통 /etc에 있는) 설정 파일들을 한 줄에 하나씩 완전한 경로를 적어 놓으면 된다. gentoo도 /etc/gentoorc라는 한개의 conffile이 있어서, 이 파일을 conffile에 써 넣는다. 5.3. dirs --------- 이 파일은 꼭 필요한 디렉토리이지만, 보통의 설치 과정(make install)에서는 만들어지지 않는 디렉토리를 지정한다. 기본적으로, 이 파일은 다음과 같이 만들어 진다: usr/bin usr/sbin 맨 앞에 있는 슬래쉬는 포함되지 않는다는 것에 주의ㅎ나다. 우리는 이 파일을 다음과 같이 바꿀 것이다: usr/X11R6/bin usr/X11R6/man/man1 하지만, 이 디렉토리는 메이크파일에서 이미 만들어진다. 때문에 우리는 dirs 파일이 필요가 없고, dirs 파일은 지워도 된다. 5.4. manpage.1.ex ----------------- *.ex로 끝나는 파일들은 각 기능들을 패키지에 포함하는 방법을 알려주는 예제이다. 이 기능들을 사용하려면, 이 파일을 편집하고 .ex 확장자를 없앤다. 필요하지 않으면 .ex 로 끝나는 파일을 지운다. 프로그램에는 맨페이지가 있어야 한다. 맨페이지가 없다면 내용을 채워 넣을 수 있는 뼈대가 여기에 마련되어 있다. 맨페이지를 만드는 방법에 대한 설명은 man(7)에 간단히 나와 있다. 이 파일을 프로그램의 이름으로 고치고 그 맨페이지가 가야 할 매뉴얼 섹션으로 확장자를 고친다. 다음은 매뉴얼 섹션의 리스트이다: 섹션 | 설명 | 보충 1 사용자 명령 실행할 수 있는 명령어나 스크립트 2 시스템 콜 커널에서 제공하는 함수 3 라이브러리 콜 시스템 라이브러리에서 제공하는 함수 4 특수 파일 보통 /dev에 있는 파일 5 파일 형식 예를 들어, /etc/passwd의 형식 6 게임 혹은 그 외 시시한 프로그램 7 매크로 패키지 맨페이지 매크로와 같은 것들 8 시스템 관리 보통 root만 실행하는 프로그램 9 커널 루틴 비표준 함수 및 내부 구조 즉, gentoo의 맨페이지는 gentoo.1이나, gentoo.1x가 된다. gentoo는 X11 프로그램이기 때문에 1x가 된다. 원 소스에는 gentoo.1 맨페이지가 없었으므로 예제와 상위소스에 들어 있는 문서들을 이용해서 직접 작성했다. 5.5. menu.ex ------------ X 윈도우 사용자가 사용하고 있는 윈도우 관리자는 보통 프로그램을 실행할 수 있도록 커스터마이즈할 수 있는 메뉴가 있다. 데비안 menu 패키지를 설치했다면, 시스템의 각 프로그램이 필요로 하는 메뉴가 자동으로 만들어 질 것이다. 데비안 정책상 필요한 것은 아니지만, 메뉴를 만드는 편이 사용자에게 편리할 것이다. 이 파일을 편집해서 gentoo를 메뉴에 추가할 수 있다. 다음은 dh_make가 기본으로 만들어 주는 파일이다: ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo" 첫번째 필드는 프로그램에서 필요한 인터페이스의 종류이다 (예, 텍스트냐 X11이냐). 그 다음은 gentoo 나타날 메뉴와 서브메뉴이다. 현재 섹션의 리스트는: /usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1 세 번째 필드는 프로그램의 이름이다. 네 번째는 프로그램의 아이콘 이름인데, 아이콘이 없다면 none으로 한다. 다섯 번째는 메뉴에 나타나게 될 실제 문장이다. 여섯 번째는 프로그램을 실행할 명령어이다. 이제 우리는 메뉴 항목을 다음과 같이 바꾼다: ?package(gentoo):needs=X11 section=Apps/Misc \ title="Gentoo" command="/usr/X11R6/bin/gentoo" 더 자세한 정보는 menufile(5), update-menus(1) 참고. 5.6. watch.ex ------------- uscan(1)과 uupdate(1) 프로그램과 함께 이 파일을 사용한다 (이 프로그램들은 devscripts 패키지 안에 있다). 이 기능을 이용해 원 소스를 가져온 사이트를 살펴볼 수 있다. 나는 다음과 같이 했다: # watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate 힌트: 인터넷에 연결된 상태에서, 이 파일을 만든 다음 프로그램 디렉토리에서 "uscan"을 실행해 본다. 그리고 해당 맨 페이지를 읽는다. 5.7. ex.doc-base ---------------- 여러분의 패키지에 HTML이나 그 외 문서가 들어 있다면 (맨 페이지와 info 문서를 제외하고), `doc-base' 파일로 그 문서를 등록해야 한다. 사용자는 dhelp(1)이나 dwww(1)로 그 문서를 찾을 수 있다. gentoo의 doc-base 파일은 다음과 같다: Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html 이 파일 형식에 대한 정보는 install-docs(8)과 doc-base 매뉴얼, /usr/doc/doc-base/doc-base.html/index.html에 있다. 5.8. postinst.ex, preinst.ex, postrm.ex, prerm.ex ------------------------------------------------- 이 파일들은 관리자 스크립트라고 한다. 이 스크립트는 패키지 콘트롤 정보로 저장되고 패키지가 설치, 업그레이드, 삭제될 때 실행된다. 지금으로서는 관리자 스크립트를 직접 편집하지 않도록 한다. 물론 할 수도 있겠지만 비교적 복잡하기 때문이다. 좀 더 자세한 정보는 Packaging Manual 섹션 6에 있으며, dh_make가 만들어 주는 예제 파일을 살펴본다. ------------------------------------------------------------------------------- 6. 패키지 빌드 -------------- 이제 패키지를 빌드할 준비가 완료되었다. 6.1. 패키지 빌드 ---------------- 해당 프로그램의의 주요 디렉토리로 들어가서 다음을 실행한다: dpkg-buildpackage -rfakeroot 이 명령어는 모든 작업을 해 줄 것이다. 여러분이 할 일은 PGP 비밀 키를 두번 입력하는 것 뿐이다. 다 끝났으면, 4개의 파일들이 위의 디렉토리(~/debian/)에 새로 만들어 진다: * _gentoo_0.9.12-1_i386.deb_ 완전한 이진 패키지이다. 다른 패키지와 마찬가지로 dpkg나 dselect를 사용해 이 패키지를 설치할 수 있다. * _gentoo_0.9.12.orig.tar.gz_ 이 파일은 원래 소스코드를 묶어 놓은 것이고, 다른 누군가가 패키지를 처음부터 다시 만드려고 할 때 사용한다. 혹은 데비안 패키징 시스템을 사용하지 않는 사람들의 경우에는 이 소스를 받아서 컴파일해야 한다. * _gentoo_0.9.12-1.dsc_ 이 파일은 소스 패키지 내용의 요약이다. 이 파일은 gentoo-0.9.12/debian/control 파일에서부터 만들어 지고, dpkg-source(1) 프로그램을 이용해서 소스 패키지를 풀 때 사용된다. 이 파일은 PGP로 사인되어 있으므로 사람들은 이 파일을 여러분이 썼다는 걸 확신할 수 있다. * _gentoo_0.9.12-1.diff.tar.gz_ 이 압축 파일은 원 소스파일에서 추가한 부분이 "unified diff"라는 형태로 들어 있다. 이 파일은 dpkg-source(1)에서 쓰인다. * _gentoo_0.9.12-1_i386.changes_ 이 파일은 현재 패키지 개정판에서 바뀐 모든 것을 기술한다. 그리고 이 정보는 데비안 FTP 아카이브 관리 프로그램에게 넘어가서 적절한 위치로 바이너리와 소스 패키지를 설치하는 데 이용된다. 이 파일의 일부분은 gentoo-0.9.12/debian/changelog 파일과 .dsc 파일에서부터 만들어 진다. 이 패키지에서 작업할 때, 프로그램의 동작 방식은 매번 변할 것이고 새로운 기능들이 계속 추가될 것이다. 여러분의 패키지를 내려받는 사람들은 이 파일을 들여다 보고 무엇이 바뀌었는지를 알 수 있다. 길다란 숫자는 해당 파일의 MD5 체크섬이다. 여러분의 파일을 내려받는 사람은 그 파일들을 md5sum(1)으로 검사해 보고, 그 숫자가 맞지 않았을 때 그 파일이 훼손되었거나 악의에 의해 함부로 고쳐졌다는 걸 알 수 있다. 이 파일은 PGP로 사인되어 있으므로, 사람들은 이 파일을 여러분이 썼다는 사실도 확신할 수 있다. 큰 패키지의 경우, debian/rules를 바꿀 때마다 처음부터 패키지를 빌드하고 싶지는 않을 것이다. 테스트 목적으로, 상위 소스를 다시 빌드하지 않고 다음과 같이 빌드할 수 있다. fakeroot debian/rules binary `install' 룰에 `install-stamp' 디펜던시가 _없다_는 점을 확인한다 (현재 기본적으로 그렇다). 그래야 `dh_clean -k`가 매번 실행된다. 모든 작업이 끝나면 제대로 업로드할 수 있도록 올바른 과정을 통해 꼭 빌드를 다시 해야 한다. ------------------------------------------------------------------------------- 7. 패키지에 오류가 있는지 검사하기 ---------------------------------- .changes 파일에 대해 lintian(1)을 실행한다; 이 프로그램은 자주 범하는 패키징 실수를 검사해 준다. 명령어는: lintian -i gentoo_0.9.12-1_i386.changes 물론 여러분의 패키지에서 만들어 지는 changes 파일의 이름을 쓴다. 무슨 애러가 있으면 (E:로 시작하는 줄), 거기에 대한 설명을 (N: 줄) 읽어보고, 실수를 수정하고, 6, `패키지 빌드'에서 설명된 대로 다시 빌드한다. W:로 시작하는 줄이 있으면, 경고 메세지일 뿐이므로 패키지에 문제가 없다고 해도 좋다 (하지만, 물론 약간 조정할 필요는 있다). dpkg-buildpackage로 빌드하고 lintian으로 검사하는 과정을 debuild(1) 명령 한 번에 할 수 있다. 패키지 내부를 mc(1)와 같은 파일 관리자로 들여다 보거나 dpkg-deb(1)을 이용해 임시 위치에 압축을 풀어 본다. 바이너리 및 소스 패키지에 필요 없는 파일이 들어가 있지 않는지 검사한다. 그 경우에 무언가 잘못이 있는 것이고 필요없는 파일이 지워지지 않은 것이다. 팁: `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz`을 실행하면 소스 파일에서 바뀌거나/추가된 파일을 알 수 있다. 또 `dpkg-deb -c gentoo_0.9.12-1_i386.deb`으로 패키지의 파일 목록을 볼 수 있다. 테스트를 위해 직접 패키지를 설치해 본다 (debi(1) 명령으로). 할 수 있으면 여러분 컴퓨터 이외의 시스템에도 설치해 보고, 무슨 문제가 있는지 살펴 본다. 나중에, 새로운 버전을 빌드하는 일이 있으면, 패키지를 제대로 업그레이드할 수 있도록 다음을 확인해야 한다: ------------------------------------------------------------------------------- 8. 패키지 업로드하기 -------------------- 여러분이 만든 새로운 패키지를 완전히 테스트 했으면 http://www.debian.org/devel/join/newmaint에 있는 내용처럼 데비안 새로운 개발자 지원 과정을 시작해도 될 것이다. 이미 공식 개발자라고 한다면 데비안 패키지를 데비안 아카이브에 업로드 해도 된다. 하나 하나 손으로 해야하지만 자동으로 해주는 도구인 dupload(1)나 dput(1)를 쓰면 된다. 여기서는 `dupload'에 대해서만 설명한다. 여기서 처음 시작해야할 일은 dupload 설정파일을 편집하는 일이고 시스템 전체에서 쓰려면 `/etc/dupload.conf'을 수정하고 자신만 쓰려면 `~/.dupload.conf' 라고 쓰면 된다. 우선 여기 에 넣을 수정사항을 보면: package config; $default_host = "ftp-master"; $cfg{"ftp-master"}{"login"} = "yourdebianusername"; $cfg{"non-us"}{"login"} = "yourdebianusername"; 1; 물론 자신에 맞게 수정하면 되고 각 옵션이 무슨 뜻인지 알려면 dupload.conf(5)를 읽어보면 된다. $default_host 옵션은 속기 쉬운 부분인데 여기서 기본으로 어떤 곳으로 업로드 큐를 선택할건지 정해준다. 기본은 "ftp-master" 이지만 여러분이 다른 곳으로 해도 되고 더 빠른 곳으로 해도 된다. 더 자세한 내용은 개발자 참고서에 있는 `/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading' 을 보면 알 수 있다. 인터넷을 연결하고 다음 명령을 실행한다: dupload --to master gentoo_0.9.12-1_i386.changes `dupload'는 파일의 .changes 파일에 들어 있는 파일에 대해 MD5 체크섬이 맞는지를 확인하고, 맞지 않을 경우 경고를 낸다. 이 경우 6.1, `패키지 빌드'에 설명된 대로 다시 빌드해서 제대로 업로드하도록 한다. `dupload'는 ftp-master의 암호를 물어보고, 패키지를 업로드하고, 필요한 경우 업로드에 대한 공지사항을 에 보낸다. ------------------------------------------------------------------------------- 9. 패키지 갱신 -------------- 9.1. 새로운 데비안 리비전 ------------------------- 해당 패키지에 버그 #54321이 보고되었다고 하자. 그리고 그 버그는 여러분이 고칠 수 있는 버그이다. 새로운 패키지 개정판을 내기 위해 할 일은: * (물론)패키지 소스의 문제를 고친다. * `dch -v -`처럼 `dch -i`로 데비안 changelog 파일에 새로운 개정판을 추가하고, 팁: 날짜는 어떻게 업데이트하죠? `822-date`나 `date -R`을 이용한다. 해당 버그에 대한 짧은 설명과 해결책을 기술한다. "Closes: #54321"이라고 쓴다. 이렇게 하면, 아카이브 관리 소프트웨어가 이 패키지를 받는 순간에 자동으로 해당 버그 보고를 종료시킨다. * 6.1, `패키지 빌드', 7, `패키지에 오류가 있는지 검사하기', 8, `패키지 업로드하기'에서 한 일을 반복한다. 이번의 차이점은 원 소스가 포함되지 않는다는 점이다. 원 소스는 변경되지 않았고 이미 데비안 아카이브에 있다. 9.2. 새로운 상위소스 릴리즈 --------------------------- 그러면 이번에는 좀 다른, 약간 더 복잡한 상황을 생각해 보자 - 새로운 상위 버전이 릴리즈되었고, 이 버전을 패키징하려고 한다. 이 때 할 일은: * 새로운 소스를 내려 받아서 그 파일(예를 들어 gentoo-0.9.13.tar.gz)을 위의 소스 트리에 놓는다 (~/debian/). * 과거의 소스 디렉토리로 이동해서 다음을 실행한다: uupdate -u gentoo-0.9.13.tar.gz 물론 파일 이름은 여러분의 프로그램의 소스 아카이브 파일 이름으로 쓴다. uupdate(1)은 해당 파일의 이름을 적절히 바꾸고, 과거의 .diff.gz 파일에서 바꾼 점들을 모두 적용하려고 시도할 것이다. 그리고 새로운 debian/changelog 파일을 만든다. * `../gentoo-0.9.13' 디렉토리로 이동한다. 이 디렉토리가 새로운 패키지 소스트리이고, 6.1, `패키지 빌드', 7, `패키지에 오류가 있는지 검사하기', 8, `패키지 업로드하기'에서 한 일을 반복한다. `debian/watch' 파일을 5.6, `watch.ex'에서 설명한 대로 설정한 경우, uscan(1)을 실행하면 자동으로 원 소스가 바뀌었는지 확인하고, 소스를 내려받고, `uupdate'를 실행한다. 9.3. 패키지 업그레이드 확인하기 ------------------------------- 새버전을 빌드했을 때, 반드시 패키지가 안전하게 업그레이드 됐는지 확인해야한다: * 이전 버전에서 업그레이드 하고 * 다시 다운그레이드 하고 없애보고, * 새로운 패키지 설치하고 * 다시 없애보고 재설치 해보고, * 완전 삭제까지 해본다. 데비안에서 여러분 패키지가 이전에 릴리즈 됐다면, 사람들은 지난번 버전에서 업그레이드 하리라 생각하고 이전버전에서 업그레이드 테스트도 해보라. ------------------------------------------------------------------------------- 10. 도움을 얻을 수 있는 곳 -------------------------- 널리 알려진 장소에 질문을 하기 전에, 부디 RTFM한다. 읽어 볼 문서는 /usr/share/doc/dpkg, /usr/share/doc/debian, /usr/share/doc/package/* 파일들과 이 글에 포함된 각 프로그램들의 맨페이지, info 페이지이다. 버그 보고를 받는다면 (진짜 버그 보고!) 여러분은 이제 Debian Bug Tracking System (http://www.debian.org/Bugs/)에 들어섰고, 거기에 있는 문서를 읽어야 한다. 그래야 버그 보고들을 효과적으로 이용할 수 있다. 에 있는 데비안 조언자의 (Debian Mentors') 메일링 리스트에 가입하면, 경험있는 데비안 개발자가 여러분의 의문을 풀어 줄 것이다. 이 리스트는 주소로 제목에 `subscribe'를 써서 이메일을 보내면 가입된다. 아직도 의문이 있다면, 에 있는 데비안 개발자의 메일링 리스트에 물어본다. 이 리스트는 주소로 제목에 `subscribe'라고 써서 이메일을 보내면 가입된다. 여러분이 이미 데비안 개발자라면 어쨌든 이 리스트에 가입해야 한다. 설령 잘 동작하더라도, 이제부터 기도를 시작해야 한다. 왜 그럴까? 이제 몇 시간 (혹은 며칠) 후면 전세계의 사용자들이 당신의 패키지들을 쓰기 시작할 것이기 때문이다. 또 중대한 오류를 범한 경우에, 분노한 수많은 데비안 사용자들로부터 메일폭탄이 날아올 것이다... 농담. :-) 마음 놓고 버그 보고에 대비한다. 패키지가 완전히 데비안 정책에 들어맞으려면 이보다 훨씬 많은 작업이 필요하다 (다시 한번 말하지만, 자세한 내용을 알려면 _실제 문서_를 읽기 바란다). 행운을 빈다! ------------------------------------------------------------------------------- 데비안 새로운 관리자 안내서 Josip Rodin 번역: 류창우 번역: 양유성 version 1.2, 6 April 2002.