다음 이전 차례

4. 미리 패키지화된 바이너리 파일

4.1 rpms, 무엇이 잘못되었나?

소스로부터 수동으로 패키지를 컴파일하고 설치하는 것은 분명히 어떤 리눅스 사용자들에게는 매우 겁나는 일이다. 그래서 인기있는 rpm과 deb 혹은 더 새로운 Stampede slp 패키지 포맷을 사용하곤 한다. rpm 설치가 보통은 부드럽고 빠를 수 있다. 어느 악명높은 운영 체제에서 소프트웨어를 설치하는 것 만큼이나 말이다. 하지만 자동으로 설치되는 미리 패키지화된 바이너리 파일의 약점에 대해서도 분명히 생각해 보아야 한다.

첫째, 소프트웨어 패키지가 보통은 먼저 "tarball"로 배포되며, 미리 패키지화된 바이너리 파일은 며칠에서 몇주 심지어는 몇달 뒤늦게 나온다는 것을 알아야 한다. 현재의 rpm 패키지는 최신의 "tarball"에 비해 적어도 마이너 버젼 2 정도 늦는 것이 일반적이다. 따라서 소프트웨어의 첨단을 따라가고 싶은 사람이라면, rpm이나 deb가 나오기를 기다릴 수 없을 것이다. 덜 인기있는 패키지라면 아예 rpm으로 만들어지지 않을 수도 있다.

둘째, "tarball" 패키지가 보다 완전하며, 더 많은 옵션을 가지고 있고, 더 최적화시키기 쉽다. 바이너리 파일의 rpm 배포본은 원래 배포본의 기능 가운데 일부를 가지고 있지 않을 수도 있다. 소스 rpm은 전체 소스 코드를 포함하고 있으며, rpm --recompile 패키지이름.rpm 이나 rpm --rebuild 패키지이름.rpm 옵션으로 컴파일하고 설치하여야 한다.

셋째, 어떤 미리 패키지화된 바이너리 파일들은 제대로 설치되지 않으며, 설치가 되었다고 해도 정상적으로 종료되지 못하고 core-dump를 낼 수 있다. 이것은 의존하고 있는 라이브러리의 버젼이 당신의 시스템에 있는 것과 다르기 때문일 수도 있고, 제대로 패키지화되지 않았을 수도 있으며, 혹은 그저 실행에 실패한 것(plain broken)일 수도 있다. 어떤 경우건, rpm이나 deb를 설치했다면, 당신은 그 rpm이나 deb 패키지를 만든 사람의 숙련도를 믿어야만 한다.

끝으로, 소스를 만지고 그것으로부터 배우기 위해서는, 소스 코드를 손 위에 갖고 있는 편이 좋다. 소스 코드를 압축 파일로 갖고 있는 편이 별도의 소스 rpm으로 갖고 있는 편에 비해 훨씬 더 수월하다.

rpm 패키지를 설치하는 것이 꼭 아무 생각없이 가능한 것은 아니다. 의존성에 문제가 있으면 rpm 설치는 실패할 것이다. 비슷한 경우로, rpm이 당신 시스템에 있는 것과 다른 버젼의 라이브러리를 요구한다면, 설치는 제대로 되지 않을 것이다. 당신이 지금 있는 라이브러리에서 없는 라이브러리로의 심볼릭 링크를 만들어준다 해도 말이다. rpm 설치가 편리하기는 하지만, "tarball" 설치가 실패하는 것과 같은 이유로 실패하는 경우가 자주 있다.

당신은 필요한 쓰기 허가권을 갖기 위해서 rpm과 deb의 설치를 root로서 해야만 하는데, 이것은 심각한 잠재적 보안 문제를 야기한다. 당신이 생각없이 시스템의 바이너리 파일과 라이브러리들을 망쳐버리거나, 심지어 당신 시스템을 파괴할 트로이 목마를 설치할 수도 있기 때문이다. 따라서 rpm과 deb 패키지를 "믿을 수 있는 자료원"으로부터 얻는 것이 중요하다. 어떤 경우에나 당신은 rpm 패키지를 설치하기 전에, rpm --cecksig 패키지이름.rpm 명령으로 (MD5 checksum과 대조하여) '서명 확인'을 해야만 한다. 마찬가지로 rpm -K --nopgp 패키지이름.rpm을 수행할 것을 강력하게 권한다. deb 패키지에서 이에 해당하는 명령은 dpkg -I | --info 패키지이름.deb 와 dpkg -e | --control 패키지이름.deb 이다.

진짜 편집증 환자(이 정도라면 편집광이라고 부르는 경우가 더 많다)라면, 패키지를 풀어서 그 구성요소를 확인하기위한 unrpm과 rpmunpack 유틸리티를 Sunsite utils/package directory의 utils/package 디렉터리에서 구할 수 있다.

Klee Diene은 설치된 .deb 파일에 문제가 있는지 MD5 checksum과 비교하여 확인하는 dpkgcert라는 실험적인 패키지를 작성했다. Debian ftp archive에서 구할 수 있다. 현재의 패키지 이름 및 버젼은 dpkgcert_0.2-4.1_all.deb 이다. "http://dpkgcert.jimpick.com" name="Jim Pick Software">사이트는 dpkgcert가 전형적인 데비안 시스템 내의 패키지들을 검증하도록 하는 실험적인 서버 데이터베이스를 운영하고 있다.

가장 단순하게는, rpm -i 패키지이름.rpm 과 dpkg --install 패키지이름.deb 명령으로 자동적으로 소프트웨어를 풀어서 설치할 수 있다. 하지만 이 명령을 맹목적으로 쓰면 당신 시스템을 해칠 수도 있으므로 주의해야 한다.

위의 경고는 정도는 덜 하지만 슬랙웨어의 pkgtool 설치 유틸리티에도 역시 적용된다. 모든 "자동화된" 소프트웨어 설치는 주의를 요하는 것이다.

martian와 alien 프로그램은 rpm, deb, Stampede의 slp, tar.gz 패키지 형식을 서로 변환해준다. 이 프로그램들을 쓰면 이 패키지들을 모든 리눅스 배포본에서 사용할 수 있다.

더 자세한 정보가 필요하면 rpm과 dpkg 명령의 man 페이지를 주의해서 읽고, RPM HOWTO와 TFUG의 Quick Guide to Red Hat's Package Manager, The Debian Package Management Tools를 참조하라.

4.2 rpms의 문제: 한 가지 예

Jan Hubicka는 xaos라는 매우 훌륭한 프랙탈 패키지를 만들었다. 그의 홈페이지에서 .tar.gz과 rpm로 된 패키지들을 구할 수 있다. 편의를 위해서 "tarball" 보다는 rpm 버젼을 사용하기로 하자.

불행하게도 rpm 버젼의 xaos를 설치하는데 실패했다. 두 별개의 rpm 판이 모두 제대로 동작하지 않았다.

rpm -i --test XaoS-3.0-1.i386.rpm 

error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1

rpm -i --test xaos-3.0-8.i386.rpm 

error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8

이상한 것은 libslang.so.0, libpng.so.0, libaa.so.1이 모두 시험된 시스템의 /usr/lib 디렉터리에 있었다는 것이다. xaos의 rpm들은 릴리즈 번호는 같아도 조금 다른 버젼의 라이브러리를 쓰도록 컴파일되었음이 틀림없다.

시험삼아 xaos-3.0-8.i386.rpm을 --nodeps 옵션을 주어 강제로 설치해 보자. xaos를 실행시켜 보지만, 작동하지 않는다. 

xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl

왜 이렇게 되는지 알아보기 위해, 계속 시도해 보기로 하자. xaos 실행파일이 어떤 라이브러리에 의존하고 있는지 찾아보기 위해 ldd를 실행시켜 보면, 필요한 공유 라이브러리가 모두 있다는 것을 보여준다. /usr/lib/libaa.so.1 라이브러리에 nm을 실행해서 그 심볼릭 레퍼런스 목록을 보면, 이 라이브러리에는 정말 __fabsl이 빠져있다는 것을 알 수 있다. 물론 이 빠져있는 레퍼런스는 다른 라이브러리에서 빠진 것일 수도 있지만... 라이브러리를 바꾸지 않는 한, 더 이상 어쩔 수가 없다.

rpm은 이정도로 충분하다. 이제 "tarball" 즉 XaoS-3.0.tar.gz을 홈 페이지나 ftp 사이트에서 다운받는다. 이 패키지를 컴파일해보기로 하자. ./configure, make를 실행시키고, 마지막으로 (루트로서) make install을 실행한다. 문제없이 작동한다.

이것은 미리 컴파일된 패키지가 그 장점 보다 더 많은 문제를 일으키는 많은 예 중의 하나일 뿐이다.

다음 이전 차례