| RedHat Linux >> System Administration for Redhat Linux
|
|||
| [목차] | |||
|
제6장 RPM 패키지 관리
3. RPM의 구조 제장 RPM 패키지 관리
. RPM의 구조 가. 의존성 RPM 패키지를 설치할 때, 리눅스 구조에 대한 약간의 지식이 필요하다. 리눅스는 리차드 스톨만이 주장하듯이, GNU/Linux라고 부르는 것이 옳다. 이말은 리눅스 자체가 OS 전체가 아님을 의미하고, 또 리눅스 각 부분이 독립적으로 개발되는 것을 의미한다. 리눅스는 MS 윈도우처럼 OS를 개발하면서 실행에 필요한 모든 구성 요소들을 한꺼번에 개발하지 않는다. 라이브러리 하나, 간단한 기능의 프로그램 하나 조차도 모두 다른 개발 계획에 의해 만들어진 것이다. 리눅스의 이런 특징 때문에 패키지를 설치할 때 항상 짚고 넘어가야 하는 것이 있다. 지금 설치하려는 프로그램이 어떤 환경을 기반으로 개발된 것인지, 혹은 어떤 프로그램을 사용해서 프론트 엔드 형식으로 동작하는 것인지, 이두가지 사항을 확인해보지 않고 패키지를 설치하게 되면, 설치한 프로그램의 정상 동작을 보장할 수 없다. 통상적인 응용 프로그램의 동작 환경을 나타내 보았다.
RPM은 이런 리눅스의 특성을 반영해서 패키지를 만들 때 그 패키지에 필요한 프로그램에 대한 정보를 넣고 있다. 그래서 가끔 하나의 패키지를 설치하려 할때 'dependency(의존성)' 오류라는 것을 볼 수 있을 것이다. 이 오류는 RPM 패키지에 들어있는 정보 파일을 사용해서 사용자의 리눅스 박스에 설치된 패키지를 검색해 본 결과 필요한 프로그램이나 라이브러리 구성 요소가 없다는 메시지이다. 보통은 의존성 오류 메시지와 함께 필요한 구성 요소들의 패키지 명이나 프로그램 명을 출력해 준다. 이정보는 패키지를 제작할 때, 패키지 안에 저장 하는 것이므로, 일정 그룹을 만든 배포판의 경우, 그 배포판의 고유 패키지 명을 출력해 주는 경우가 있다. 예를 들어, 미지 OS라면 패키지 명에 'mz', 수세리눅스 라면, 'suse'이런식으로 그 배포판에서만 쓰는 패키지 명을 출력해 주는 경우가 있다. 배포판을 만든 개발 그룹에서 자신들이 만든 배포판안에서 패키지를 찾을 수 있게 일부러 일반적인 구성 요소의 버전과 이름이 아닌 패키지 명을 넣어 놓는다. RPM은 의존성 오류가 해결되기 전에는 즉, 동작하는 데 필요한 모든 구성요소가 설치되어 있지 않으면, 피키지를 설치하지 않는다. 가끔 이런 의존성을 무시하고, 설치해야 하는 때도 있는데, 이럴 때는 추가 옵션을 설정하면 된다. 의존성 오류는 사용자 입장에서는 약간은 귀찮은 일이지만, 리눅스 박스에게는 OS를 안정적으로 운영할 수 있게 도움을 준다. RPM의 구조 중에서 독특하고 강력한 기능이다. 의존성만을 알려주는 것이 아니라 필요한 패키지를 검색해서 판단하므로, 관리자가 일일이 프로그램을 검색하는 일을 덜어 준다. 나. 패키지 디렉토리 구조 RPM 패키지들은 과연 어디에 설치되는 것일까 ? Make 명령을 사용한 컴파일 작업은 보통 /usr/local에 그 결과물이 남게 마련이다. 하지만 RPM 패키지들을 설치하게 되면, 특정한 위치에 프로그램 이름을 가지는 하나의 디렉토리를 만들어서 설치하는 것이 아니라 리눅스의 기본 디렉토리 구조에 따라 설치하게 된다. 예를 들어 파이썬 2.0 RPM 패키지를 설치한다고 했을 때, 원하는 디랙토리에 파이썬2라고 디렉토리를 만들고 설치하는 것이 아니다. 이렇게 만든다면 프로그램의 삭제는 쉽게 될 것이다. 하지만 리눅스처럼 각 디렉토리의 용도가 정해진 OS의 경우, 일일이 설정 파일을 바꾸고 링크를 걸어주어야 한다. 그리고 리눅스의 일반적인 디렉토리 구조를 따르지 않고 설치하게 되면, 프로그램을 불러오거나 실행시키는데 어려움을 겪게 된다. 일반적으로 /usr/ 밑에 있어야 할 프로그램들이 / 밑에 있다고 생각해 보라. 혹은 /bin/ 밑에 있어야 할 프로그램들이 /usr/src밑에 있다든가 하면 프로그램을 실행할 수도 없고, 조작하는 관리자도 프로그램을 실행시키는데 어려움을 겪을 것이다. 그래서 RPM 패키지들은 리눅스의 기본 디렉토리 구조 즉, /bin, /etc 등에 맞추어서 세작되어 있다. 단순히 압축해서 패키지를 하나의 파일로 만든 것이 아니라 프로그램이 실행되기 위해 위치해야 할 디렉토리 구조까지 담고 잇는 것이다. /sbin, /lib에 설치되어야 하는 파일들이 있다면, 패키지에 담겨있는 디렉토리 정보에 따라 '/'를 기준으로 덧씌우듯 파일을 원하는 디렉토리에 설치하게 된다. RPM 바이너리 패키지를 제작할 때는 가상으로 '/'를 지정해서 그 디렉토리를 기준으로 설치되었을 때 있어야 할 디렉토리 구조를 똑같이 구축하고 제작한다. 위에서 예로 든 파이썬 2.0의 소스를 가져다가 바이너리 RPM패키지를 만든다고 하면, 일단 /tmp 혹은 작업할 디렉토리를 먼저 만들고, 그 디렉토리를 가상의 '/'로 생각하고, 작업을 하게 된다. 디렉토리 구조를 그려보면 다음과 같은 형식이다. (임의로 필요한 디렉토리들을 만들어 보았다) / (실제 루트) ├─ /bin ├─ /sbin ├─ /etc ├─ /lib ├─ /usr ├─ /proc ├─ /var ├─ /boot ├─ /root ├─ /home └─ /tmp (가상 루트 : 패키지 작업을 할 디렉토리) ├─ /bin ├─ /etc ├─ /lib └─ /usr/python2 패키지를 만들 때 가상 루트 밑의 구조를 그대로 RPM 패키지 안에 넣는 것이다. 그후에 RPM 패키지 내부의 정보 파일에 가상 루트인 /tmp를 실제 루트인 '/'으로 대체시켜서 설정해 놓으면 설치할 때 만들었던 디렉토리 구조를 그대로 찾아서 파일을 복사하고, 디렉토리가 없으면 디렉토리를 생성해서 설치하게 된다. |
|||
| [목차] |
System Admin
