6. 배포본 제작 방법

6.1. tar 파일은 항상 하나의 새로운 디렉토리에 풀어지도록 해라

초보 개발자가 범하는 가장 성가신 실수 중의 하나가 tar 파일을 배포본이 있는 현재의 디렉토리에 압축이 풀리도록 만드는 것이다. 이것은 현재 디렉토리에 이미 존재하는 파일을 덮어쓸 위험이 있다. 이런 실수를 절대로 하지 마라!

그 대신, 프로젝트의 이름을 따서 만든 하나의 공통 디렉토리를 포함하는 압축 파일을 만들어서, 이 파일들이 현재 디렉토리 아래에 위치한 새로운 디렉토리에 압축을 풀 수 있도록 해라.

여기 makefile 트릭(trick)이 있다. `foobar'라는 배포본의 디렉토리를 가지고 있으며 SRC가 배포본의 파일 리스트를 포함하고 있다고 가정하면 다음과 같이 하면 된다.

foobar-$(VERS).tar.gz:
	@ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST
	@(cd ..; ln -s foobar foobar-$(VERS))
	(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`)
	@(cd ..; rm foobar-$(VERS))

6.2. README를 포함시켜라

README 또는 READ.ME 파일을 포함시키면 그것은 배포본의 지침서가 될 것이다. 오래된 관행에 따라, 소스의 압축을 푼 사용자는 이 파일을 가장 먼저 읽게 된다.

README 파일에 포함되어야 할 내용들은 다음과 같다.

1. 프로젝트의 간단한 설명

2. 프로젝트 웹사이트의 주소(만약 있을 경우)

3. 개발자의 제작 환경과 설치상의 잠재적인 문제점

4. 중요 파일과 하위 디렉토리 구성에 대한 설명(로드맵)

5. 제작/설치에 관한 설명이나 그것을 포함한 파일의 이름(일반적으로INSTALL).

6. 프로젝트 진행자/참여자의 명단이나 그것을 포함한 파일의 이름(일반적으로CREDITS).

7. 프로젝트의 최근 소식이나 그것을 포함한 파일의 이름(일반적으로NEWS).

6.3. 표준 명명(naming) 규칙을 존중하고 따르라

README 파일을 보기 전에도 용감한 탐험가(사용자)는 배포본의 최상위 디렉토리에 있는 파일을 훑어볼 것이다. 파일의 이름은 그 자체로 정보를 포함하고 있다. 일반적인 명명 규칙을 따름으로써 사용자에게 다음에 무엇을 보아야 할지 실마리를 제공해 줄 수 있다.

여기 몇 개의 일반적인 최상위 파일 이름과 그들이 의미하는 것이 있다. 모든 배포본이 이 파일들 전부를 필요로 하진 않는다.

대문자로 된 파일은 제작(build)을 위한 컴포넌트라기 보다는 패키지에 관한 정보(metainfomation) 를 포함하는, 사용자가 읽을 수 있는 파일임을 기억하기 바란다.

FAQ를 만들어 놓음으로써 상당부분의 고통을 덜 수 있다. 프로젝트에 관해 빈번하게 물어오는 사항들은 FAQ에 정리하도록 한다. 그러면 질문이나 버그리포트를 보내기 전에 FAQ를 읽어볼 것이다. 잘 정리된 FAQ는 사용자 지원에 대한 프로젝트 관리자의 부담을 엄청나게 줄여준다.

각각의 공개 배포본마다 시간정보를 포함하는 HISTORY 또는 NEWS 파일을 만드는 것이 좋다. 다른 어떤 점보다도, 만약 특허와 관련해서 소송이 발생했을 때 (아직까지는 그런 경우가 없지만, 있을 경우를 대비하는 것이 좋다.) 이것은 누가 먼저 시작했는지를 알려주는 주요 기록이 된다.

6.4. 업그레이드를 고려한 설계를 해라

새로운 공개판을 발표할 때마다 소프트웨어는 변하게 될 것이다. 이러한 변화 중에서 이전 버전과 호환이 안되는 경우도 있을 것이다. 따라서, 이런 경우엔 설치에 관한 디자인을 할 때 심각하게 고민해야 한다. 왜냐하면 똑같은 시스템에 여러가지 버전의 소프트웨어가 동시에 존재할 수 있도록 해야 하기 때문이다. 이것은 라이브러리에 있어서 특히 중요하다. API의 변화에 따라 모든 클라이언트 프로그램을 고정된 방식으로 업그레이드하는 것을 기대할 수는 없다.

Emacs, Python 그리고 Qt 프로젝트는 이를 처리하는 좋은 방법을 보여준다. 버전번호를 붙인 디렉토리 이름을 사용하는 것이다. 설치된 QT 라이브러리의 계층구조는 아래와 같다. (${ver} 은 버전 번호이다.):

/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin          # moc의 위치
/usr/lib/qt-${ver}/lib          # .so의 위치
/usr/lib/qt-${ver}/include      # 헤더 파일의 위치

위와 같은 방식으로 여러 버전을 동시에 수용할 수 있다. 단, 클라이언트 프로그램은 사용하고자하는 라이브러리의 버전을 명기해야 하는 부담이 있긴 하지만, 이것은 인터페이스 자체를 완전히 바꾸는 것에 비하면 아주 조그만 부담에 지나지 않는다.

6.5. RPM으로 제공해라

설치할 수 있는 바이너리 패키지의 사실상의 표준 형식은 레드햇 패키지 매니저, RPM이다. 가장 인기 있는 리눅스 배포본에 사용되며 실질적으로 다른 모든 리눅스 배포본(데비안과 슬랙웨어는 제외; 데비안에서는 가능하다.)에서도 사용된다.

따라서, 프로젝트 사이트에서 설치 가능한 RPM과 소스 tar파일을 동시에 제공하는 것이 가장 바람직하다.

또 소스 tar 파일 내에 RPM의 스펙 파일을 포함시키고, makefile 안에 RPM을 생성할 수 있는 파일을 넣는 것이 좋다. 스펙 파일은 '.spec'이라는 확장자를 가져야 한다. 'rpm -t' 명령을 쓰면 tar 파일에 있는 스펙 파일을 찾을 수 있다.

Makefile과 version.h를 분석하여 자동으로 올바른 버전 번호를 설정하는 쉘 스크립트를 이용하여 spec 파일을 생성해라.

주의:소스 RPM을 제공한다면, 프로그램이 /tmp 또는 /var/tmp에 만들어지도록 BuildRoot를 사용해라. 그렇지 않으면, 'make install'과정 중에 설치 프로그램이 파일들을 실제 최종 위치에다 설치할 것이다. 이러한 일은 파일의 충돌이 있는 경우나, 패키지 설치를 원하지 않는 경우에도 일어날 수 있다. 이렇게 하면 모든 파일들은 설치되고 시스템의 RPM 데이터베이스는 이것을 알지 못한다. 이런 좋지 않은 SRPMS의 행위는 지뢰밭을 만들게되므로 삼가야 한다.