rpm설치가 편한데 소스컴파일 설치를 왜 하는거죠?
제 나름대로 차이를 정리하자면 다음과 같습니다.
rpm 은 말 그대로 특정 버전과 환경에 맞게 패키지 된 버전입니다.
특히 바이너리 rpm 은 , 일반적인 빌드 환경에 맞게 되어있어서,
부분적인 업그레이드를 했거나, 사용자가 별도의 모듈을 업그레이드 할 경우에는
잘 동작하지 않을 수도 있겠지요.
rpm 도 바이너리 rpm 과 소스 rpm 이 있습니다.
특히 rpm 이 좋은 점은 해당 rpm 을 설치할 때 관련되는 rpm 을 검사하고
쉽게 설치가 가능하다는 점인데요.
커널이나 기본적인 라이브러리 (gcc, python, perl, apache) 에 의존적인 rpm들은
버전이 다양하고, 환경도 다를 수 있으므로 주의 해야 합니다.
마지막으로 소스 (일반적으로 tar.gz 혹은 bzip 으로 묶인 파일) 를
갖고 빌드할 경우는 , 다양한 커널환경에서 해당 모듈을 이용가능합니다.
하지만 직접 바이너리를 빌드하고 설치해야 하므로,
설치하기가 까다롭고 노력이 많이 들어갈 수도 있습니다.
따라서 일반적으로 저는 다음과 같이 설치를 합니다.
1. 바이너리 rpm.
- rpm 모듈이 시스템의 전반적인 부분에 영향을 주거나, 커널과 같이
시스템에 밀접하지 않은 부분의 경우에 주로 설치한다.
단점:
이미 빌드된 rpm 이므로 , 해당 모듈의 제어나 변경이 용이하지 않다.
내 플랫폼 (레드햇, 페도라... ) 에 맞는 rpm 을 찾지 못할 수도 있다.
순수 응용프로그램.
(예: ethereal, ...)
2. 소스 rpm
- 네트워크 모듈과 같이 드라어버나, 커널과 연관이 있는 모듈의 경우에
설치한다. 설치할 때 설정의 변경이 필요할 경우에 특히 유용하다.
apache 에 python, trac, subversion 등을 연결한다거나....
단점:
빌드에 노력이 들어가고, 설치된 버전에 맞는 소스를 제대로 구해줘야 한다.
(예: apache, )
3. 소스
- 커널과 밀접한 연관을 맺고 있거나,
구성이 복잡해서 수동으로 작업을 해줘야 하는 경우,
개발이나 작업을 위해서 직접 사용해야 할 모듈의 경우에는 직접 설치한다.
(예: trac, subversion )
단점:
빌드가 어렵다. 의존성 검사가 어려우므로 꼼꼼히 확인해서 빌드해야 한다.