System Admin

RedHat Linux >> System Administration for Redhat Linux

[목차]

제6장 RPM 패키지 관리     2. RPM의 역사 그럼 간단하게 RPM이 발전해온 역사를 살펴보도록 하자. 래드헷 리눅스가 처음 발표된 것이 오래 전의 일은 아니지만, 많은 변화가 있었고, 많은 RPM의 원형들이 있었다. 가. RPP 가장 처음 발표돼 래드햇 리눅스에서 사용되었던 프로그램이다. 특징을 살펴보면 다음과 같다. - 커맨드를 이용한 설치와 제거 - 설치와 제거 전과 후에 스크립트를 사용할 수 있다. - 패키지의 상태를 점검할 수 있다. - 패키지 쿼리가 가능하다. 이 기능들은 지금의 RPM 프로그램에도 포함되어 있는 것으로, RPM의 기본 기능이라고 할 수 있다. 위의 기능이 지금까지도 쓰일 만큼 강력하고 발전적인 기능이기는 하지만, 문제점 또한 있었다. 원시소스코드를 사용한 패키지를 만들 수 없었다. RPP에 맞게 설계된 다른 소스 코드를 이용해야 했다. 이 문제 때문에 패키지를 만들 때 개발자들은 불편함을 감수해야 했다. RPP 소스코드로 패키징 된 프로그램이 확실하게 동작할 것인지 확인할 수가 없었다. 바이너리 파일을 담은 패키지가 아닌 소스코드를 담은 패키지였으므로, 실행 여부를 패키지를 설치하기 전에는 알아볼 수 없었다. 이 문제는 많은 패키지를 사용할 경우 문제가 되었다. 단 하나의 플랫폼만이 지원되었다. 리눅스 패키지 중에는 플랫폼에 따라 달라지는 프로그램과 그렇지 않은 프로그램이 있지만, RPP의 경우 단 하나의 플랫폼만이 지원되었다. 나. PMS/PM 레드햇사에서 제작한 RPP와는 다르게 다른곳에서도 패키지 관리자를 만들어 내게 되었다. Rik Faith가 주도한 모임에서 PMS라는 약간 관점이 다른 패키지 관리자를 만들어 낸다. RPP가 RPP에서 쓰이는 특별한 소스코드를 이용해야 하는 반면, PMS는 원시 소스코드를 그대로 이용하게 제작된 것이다. 원시 소스코드를 사용함으로써 개발자들에게 편한 패키징 환경을 마련해 주었고, 이 개념은 지금의 RPM 제작에 많은 도움을 주었다. 하지만 PMS의 패키지 상태 점검과 데이터베이스 쿼리 기능은 비효율적이었다.. 이후 Rik Faith와 Doug Hoffman이 레드햇사와 접촉해서 RPP와 PMS를 합친 현태의 패키지 관리자를 만들어낸다. 그것이 바로 PM이다. PM은 RPP와 PMS의 장점을 모아 만들었으나 , 결점 또한 합쳐져 버렸다. 비효율적인 디자인의 데이터베이스와 다양한 플랫폼을 지원하지 못했다. 상업 소프트웨어에서는 사용되지 않았다. 다. RPM V.1/V.2 현재 사용되고 있는 RPM 프로그램은 RPM V2이다. 지금의 RPM의 원형인 RPM V.1을 보면, 기존의 PM, PMS, RPP에서 나타났던 문제점과 개선점을 많이 반영한 것이 특징이다. RPM V.1의 경우 펄을 사용해 디자인해서 개발자들의 편의를 도왔다. 그 외에 패키지에 대한 설정이 자동으로 이루어졌고, rebuilding이 쉬워졌으며, 사용하기 편한 커맨드들이 도입되었다. 하지만, RPM V.1에도 단점은 있었다. 펄로 제작되었기 때문에 실행 속도가 느렸고, 프로그램의 크기가 컸다. 게다가 여전히 취약한 데이터 베이스와 다중 플랫폼 지원을 하지 못하는 점은 문제점으로 지적되었다. 이후 공개된 RPM V.2는 V.1을 교훈삼아 많은 발전이 있었다. 간단하게 요약하면, - C 코드로 다시 짜여졌다. 이로 인해 프로그램의 속도가 향상되었고, 크기가 줄어들었다. - 데이터베이스를 다시 디자인했고, 쿼리 속도 또한 향상시켰다. - RPM 라이브러리가 제작되어 다른 프로그램에서 RPM 프로그램의 기능을 사용할 수 있게 되었다. 지금까지 RPM의 역사를 살펴 보았다. 이제 패키지들의 구조를 알아보자.

[목차]