Linux 와 FreeBSD의 패키징 방식의 장점의 흡수와
뭐 아시겠지만,
Linux의 경우는 rpm,deb 두 가지 방식으로 패키징이 되고 있습니다.
근데 문제가 deb는 문제가 아니고 요 레드햇사의 rpm인데...
레드햇에서 표준으로 만든답시고 난리를 쳐서리...
지금은 가장 많이 쓴 방식이 되었지만 결국 이게 혼란의 원인이 되었습니
다.
칼데라, 터보리눅스, 수세도 레드햇과 마찬가지로 rpm을 쓰는데..
이게 서로간의 호환이 안된다는 겁니다. 같은 버젼의 패키지도 의존성 에
러나고 만든 사람에 따라 회사에 따라 여러가지 문제점이 나타난다는 걸
아실겁니다.
예를 들어서 국내의 배포판들은 특히 더 그렇지요.
같은 이름의 패키지 깔면 서로 파일을 겹쳐쓰고 지우고 -_-
또다시 라이브러리 뭐 필요하다고 그러고...
이에 비해 FreeBSD의 경우는 단일 port방식으로써
거의 완벽에 가까운 패키징 방식의 일원화와 i18n의 체계화가 이미 완성되
어 있습니다.
데비안의 경우는 좀 더 낳은데, 그래도 바이너리 배포방식은 시스템에 따
라 크리티컬한 문제가 발생할수도 있는 요지를 남깁니다.
예를 들어 i586이나 i686으로 컴팔하면 AMD 씨퓨인 애슬론이나 썬더버드같
은 씨퓨엔 최적화가 덜된 컴파일 옵션이 있기 때문이지요.
역시 최고의 방식은 프비의 port라는 결론입니다.
이제 국내 배포판도 외국의 배포판에 의지할 필요가 없습니다.
아예 프비의 port방식을 리눅스에도 적용하여 나갑시다.
port를 리눅스에서도 쓸수 있는건 아는데,
것보다 아예 기본 패키징 시스템을 port로 하는건 어떤지요.
의견 바랍니다. 이제 rpm의 디펜던시 어쩌고 하는 에러에서 벗어납세다.
음.... 바이너리 패키지의 성능이나 기타 문제라면debian에서 소
음.... 바이너리 패키지의 성능이나 기타 문제라면
debian에서 소스 패키지 받아다가 빌드해서 쓰면 되지 않나...
debian을 쓰고 있지만 deb를 만드는 것에 대해서는 하나도 모르지만..
포트에서 빌드하더라도 시스템 관리 정책이 다른 배포본에서는 별소용이
없을 겁니다.
같은 rpm인데로 배포본마다 제각각인 건 어쩔수 없는 것 같은디...
파일포맷은 rpm을 쓰더라도 리눅스 배포본을 만드는 사람마다 각자 정책
이라는 것이 있을테니....
데비안의 경우는 거의 편집증이라고 생각될 정도로 패키지 관리를
엄격하게 하니깐....
횡수....
저는 FreeBSD를 써보지는 못했지만...(조만간 써볼 겁니다. ^^;
저는 FreeBSD를 써보지는 못했지만...(조만간 써볼 겁니다. ^^; )
port가 무엇인지는 대충 알고 있습니다.
단적으로 말해서, FreeBSD의 port를 리눅스 패키징 시스템과 통합한다는 게
현실적으로 가능한지 의문입니다.
서로의 특성이 너무 다르잖아요.
리눅스의 패키지는 바이너리 패키지를 묶어놓아 빠른 시간 안에 설치하고
사용하는 것을 목적으로 하지만, port는 필요할 때마다 소스를 컴파일해서
설치하는 구조이지 않습니까. 이것만 봐도 통합이 쉽지 않을 것임을 알 수 있죠?
Port에는 의존성 검사/처리 기능이 훨씬 미약할테니
이것을 리눅스로 가져오는 것 자체가
하나의 패키지 시스템을 새로 만드는 것만큼 어려울 것 같습니다.
포트 자체의 의존성 검사는 아주철저합니다. 그점은 걱정안하셔도 되
포트 자체의 의존성 검사는 아주
철저합니다. 그점은 걱정
안하셔도 되는데... 문제는
바이너리 패키지에 deb나 rpm만큼의
기능이 없다는 것입니다.
가령, 래드햇(또는 그 계열)
배포본에서도 항상 모든 패키지를
빌드할 때 최소 설치만 깔아놓고 그
위에서 빌드한다고 생각해
보세요. 제가 보기에는 40% 이상의
패키지는 빌드가 안됩니다.
왜냐하면 의존성을 잘못 적었기
때문이죠.
이전에 래드햇 rpm 들여다볼
때에는(지금도 크게 사정이 나아진
것 같지는 않습니다만) 필요한
의존성 정보를 정확하게 주지
않는 경우가 많습니다. 즉
암시적으로 사용하는데도 그게
필요하다고 써 주지 않는 경우가
많다는 거죠. 심지어 gnome
어플리케이션인데도 gnomelibs나
gnomecore에 대한 Requires
문장 하나 없는 경우도 보았습니다.
Fresh install에서
그 rpm 빌드하려면 고생 꽤나 할
겁니다 :) 뭐가 필요한지도
모르니...
포트는 FreeBSD의 경우 베이스
시스템에서 항상 컴파일한다고
생각하기 때문에 그런 문제가
없습니다. 혹 있다고 해도
매일 돌아가는 패키지 빌드
클러스터에서 결과를 알려주니
그거 봐서 고치면 되고요.
deb도 그 수준의 철저한 의존성
검사를 제공하는데 rpm은 좀
만드는게 주먹구구이다
보니(래드햇마저!) 그런 문제가
있는
것이 사실입니다. 개인적으로 만든
것은 말할것도 없겠죠...
--
익스펙토 페트로눔
최적의 성능을 발휘하는데는 port 가 좋겠지만..설치하는데 시간
최적의 성능을 발휘하는데는 port 가 좋겠지만..
설치하는데 시간이 너무 오래걸려서..
(바이너리 패키지에 비해..)
하여간 어떻게 되든..
같이 쓰는 것은 몰라도..
완전한 port 로의 통합이라면.. 반대합니다..
바이너리 패키지는 반드시 있어야 되구요..
(프비에도 있자나염?)
그리고 바이너리 패키지중..
관리가 가장 편한건 deb 같구요...
그럼 푸다닥..
FreeBSD 포트나 rpm을 많이 만들어본 입장에서(deb는 많
FreeBSD 포트나 rpm을 많이 만들어
본 입장에서
(deb는 많이 접해보지 못했습니다만
최근에 좀 보았고...)
말씀드리면, 대체적으로 포트의
단점은 다음과 같습니다.
- rpm -Uvh 식의 업그레이드 불가
(지우고 다시 깔거나 그냥 덮어
써야 합니다)
- suggestion, conflict 개념 없음
- 세밀한 의존성 버전 제어 불가
- revision기능 없음
rpm은
foovar-xx-rev.arch.rpm식으로
같은 패키지 중이라도 고치면
리비전이 올라가죠.
입니다. 이걸 보완하기 위해서
최근에 PortsNG니,
PORTREVISION, PORTEPOCH등의 여러
보안책이 제시되고
급기야 Port Option에 대한
페이퍼까지 나오는 마당입니다만,
이것이 정비되어 deb급의 안정된
방향이 되기까지에는 좀 시간이
걸릴 겁니다. 약 1년 정도...
게다가 BSD측에서 보면 NetBSD,
OpenBSD, FreeBSD가
서로 비슷한 포트 시스템을
사용하지만 그것도 설치 디렉토리나
컨벤션이 약간씩 달라서 통합
이야기까지 나오는 실정이죠.
국제화 기능에 대해서는
FreeBSD측은 무차별적으로 패키지를
받아들이기 때문에 사용자의 신중한
선택이 요구됩니다.
가령 한국어 gs는 2가지, 일본어
gs는 4-5가지 정도 제공되고
여기 원본 gs가 4가지 정도
제공되는데 사용자는 무엇을
설치해야
할까요.
이점에 있어서는 일관성을 중시하는
deb가 가장 좋습니다만 다만
너무 딱딱하고 유연성이 없는 감이
있습니다. 너무 완벽성을
추구한다고나 할까요.
rpm은 쉽고 간편하지만 중앙집중적
관리가 안되는 관계로 수많은
변종을 낳습니다. 물론 이것은 소위
말하는 linux-way입니다.
그것 나름대로의 가치는 있는
것이지요. 무식하기는 하지만
별로 어렵지도 않고요.
게다가 FreeBSD의 패키지 체제나
데비안 트리가 확고한 현재와
같은 구성을 갖추기 까지에는
수많은 분들의 수년간의 노력이
있었습니다. 이걸 그냥 가져다
쓴다고 해서 문제가 해결되는게
아니죠. 누가 정도가 아니라
수십명이 지속적으로 관리하고
수정하고 개선해 나가야 하는
것입니다. 그런 문제에 대한 확고한
의지가 없다면 공허한 목소리일
따름입니다.
--
익스펙토 페트로눔