6.3. 패키지 관리

6.3.2.1. 모든 것은 내 머릿속에 있다!

그렇다, 이것은 패키지 관리 기법이다. 어떤 사람들은 패키지들을 샅샅이 알고 있고 각 패키지에 의해 어떤 파일들이 설치되는지 알기 때문에 패키지 관리자의 필요성을 느끼지 못한다. 패키지가 변경되면 전체 시스템을 재구축할 계획이어서 패키지 관리가 필요 없는 사용자도 있다.

6.3.2.2. 별도의 디렉토리들에 설치

이는 설치를 관리하는 데 별도의 패키지가 필요 없는 단순한 패키지 관리법이다. 각 패키지는 별도의 디렉토리에 설치된다. 예를 들어 /usr/pkg/foo-1.1에 foo-1.1 패키지를 설치하고 /usr/pkg/foo에서 /usr/pkg/foo-1.1로 심볼릭 링크를 만든다. 새 버전 foo-1.2를 설치하면, /usr/pkg/foo-1.2에 설치되고 이전 심볼릭링크는 새 버전의 심볼릭링크로 대체된다.

PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH, CPPFLAGS 등의 환경 변수에 /usr/pkg/foo를 추가해야 한다. 패키지가 몇 개 이상으로 많아지면, 이 기법은 관리불능이 된다.

6.3.2.3. Symlink 스타일 패키지 관리

기존 패키지 관리 기법의 변형이다. 각 패키지는 이전 방법과 유사하게 설치된다. 그러나 symlink를 만드는 대신 각 파일이 /usr 계층으로 symlink된다. 이러면 환경 변수를 확장하기 위해 수정할 필요가 없어진다. 사용자가 심볼릭 링크를 생성해서 생성을 자동화할 순 있지만 많은 패키지 관리자가 이 방식을 사용해서 작성되었다. 인기 있는 것들 중에는 Stow, Epkg, Graft, Depot 등이 있다.

실제로는 /usr/pkg 계층에 설치되었지만 패키지가 /usr에 설치된 것으로 인식되도록 설치를 조작해야 한다. 이런 식으로 설치하는 것은 여간 복잡한 일이 아니다. 예를 들어 패키지 libfoo-1.1을 설치한다고 가정하면 다음 명령은 패키지를 제대로 설치하지 못할 수도 있다:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

설치는 되지만 의존 패키지는 예상했던 대로 libfoo에 연결되지 않을 수 있다. libfoo에 링크되는 패키지를 컴파일하면 예상했던 /usr/lib/libfoo.so.1이 아닌 /usr/pkg/libfoo/1.1/lib/libfoo.so.1과 연결된 것을 알 수 있다. 올바른 방법은 DESTDIR 전략을 사용하여 패키지를 가짜로 설치하는 것이다. 이 방식은 이렇게 작동한다:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

대부분의 패키지가 이러한 방식을 지원하지만, 그렇지 않은 패키지도 있다. 패키지가 이 방식을 지원하지 않으면 수동으로 설치해야 하거나 문제가 있는 패키지를 /opt에 설치하는 것이 더 낫다.

6.3.2.4. 타임스탬프 기반

이 기법에서는 패키지가 설치되기 전에 파일에 타임스탬프를 찍는다. 설치 후 적절한 옵션과 함께 간단한 find 명령을 사용하면 타임스탬프 파일이 생성된 후 설치된 모든 파일의 로그를 생성할 수 있다. 이 방식을 채택한 패키지 관리자는 install-log이다.

이 방법은 단순하다는 장점이 있지만 두 가지 단점이 있다. 설치 중에 파일이 현재 시간 이외의 타임스탬프와 함께 설치되면 패키지 관리자가 해당 파일을 추적하지 않는다. 더구나 이 방법은 한 번에 하나의 패키지를 설치할 때만 사용할 수 있다. 두 개의 패키지가 서로 다른 두 개의 콘솔에 설치될 때는 로그를 신뢰할 수 없다.

6.3.2.5. 설치 스크립트 추적

이 방식은 설치 스크립트가 수행하는 명령을 기록하는 것이다. 사용할 수 있는 두 가지 기법이 있다:

LD_PRELOAD 환경변수를 설치 전에 미리 로드할 라이브러리를 가리키도록 설정할 수 있다. 설치하는 동안 이 라이브러리는 cp, install, mv 등 다양한 실행 파일에 자신을 첨부하고 파일 시스템을 수정하는 시스템콜을 추적해서 설치 중인 패키지를 추적한다. 이 방식을 사용하려면 모든 실행 파일이 suid나 sgid 비트 없이 동적으로 연결되어야 한다. 라이브러리를 미리 로드하면 설치 중에 원치 않는 부작용이 발생할 수 있다. 따라서 패키지 관리자가 아무 것도 깨뜨리지 않고 필요한 모든 파일을 기록하도록 몇 가지 테스트를 하는 것이 좋다.

두 번째 방식은 설치 스크립트를 실행하는 동안 발생하는 모든 시스템콜을 기록하는 strace를 사용하는 것이다.

6.3.2.6. 패키지 아카이브 생성

이 방식에서는 앞서 Symlink 스타일 패키지 관리에서 설명한 대로 패키지 설치를 별도의 트리로 위장한다. 설치가 끝나면 설치된 파일들로 패키지 아카이브를 생성한다. 이 보관 파일은 로컬 컴퓨터나 다른 컴퓨터에 패키지를 설치하는 데 사용할 수 있다.

이 방식은 상용 배포판에서 찾을 수 있는 대부분의 패키지 관리자들이 사용한다. 이 방식을 따르는 패키지 관리자의 예로는 RPM (참고로, Linux Standard Base Specification에 필요), pkg-utils, 데비안의 apt, 그리고 젠투의 Portage system이 있다. LFS 시스템에 이런 스타일의 패키지 관리 방식을 채택하려면 http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt을 참고하라.

의존성 정보를 포함하는 패키지 파일의 생성은 복잡할 뿐더러 LFS의 범위를 벗어난다.

슬랙웨어는 패키지 아카이브에 tar 기반 시스템을 사용한다. 이 시스템은 더 복잡한 패키지 관리자들같이 의도적으로 패키지 의존성을 처리하지 않는다. 슬랙웨어 패키지 관리에 대한 자세한 내용은 http://www.slackbook.org/html/package-management.html을 참고하라.

6.3.2.7. 유저 기반 관리

이 LFS만의 독특한 방식은 Matthias Benkmann이 고안했으며 힌트 프로젝트에서 이용할 수 있다. 이 방식에서 각 패키지는 표준 위치에 별도의 사용자로 설치된다. 패키지에 속하는 파일은 사용자 ID를 확인하여 쉽게 식별할 수 있다. 이 방식의 특징과 단점은 이 절에서 설명하기에 너무 복잡하다. 자세한 내용은 http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt의 힌트를 참고하라.