누구 Solaris에서 패키징 해보신 분 있나요 ? 한번 해보려 했는데,
으윽... 메뉴얼이 없어서 그런지... 겨우 겨우 만들었습니다.
tarball 수준 ?
비교할 만한 것은 deb, rpm 이 아닐까요...
소스레벨에서의 관리에 대한 측면에서 얘기하자면,
deb 패키징은 한번도 안해봤지만, make -f debian/rules 가
먹는 것을 보고 깜딱 놀랬었던 적이 있지요. 요즈음 안되는 것 같더군요.
(debian specific 해진 부분이 많아졌다는 얘기)
deb 은 많은 융통성을 제공하고, 좀더 유닉스적인 냄새가 나는 것
같습니다. 따라서, 복잡하고 다루기가 까다롭다고 느껴지죠.
rpm은 편리하긴 하지만, 너무 일괄적이고 융통성이 없다는게 흠...
(제가 아직 방법을 몰라서인지...) 컴파일이 완료된 후에, 바이너리만을
가지고 패키징하려 하면, 트릭을 써서 해야 합니다. 안그러면
애써 컴파일 해놓은 것을 싸그리 날려버리고 다시 컴파일을 -_-;;
make -f debian/rules 로 해보지는 않았지만,
그냥 패키지의 루트디렉토리에서 debian/rules 로
바로 실행시킬 수는 있습니다. 특히 컴파일하는데
오래걸리는 것을 할 때는 참 편리하지요.
dpkg-buildpackage 를 쓰면 처음부터 시작하던데,
그냥 rules 파일을 쓰면 옵션만 주는 것으로 중단
된 곳에서 시작할 수 있으니까요.
그리고 데비안이 레드햇보다 낳은 점은 일관성이라
고 봅니다. 패키징을 왜 하는지 곰곰히 생각해보면
이 일관성이 얼마나 큰 장점인지 알 수 있게 되겠
지요.
데비안 패키지의 단점입니다. 데비안 개발자들 사이에 이 문제를
해결하기 위한 여러 제안들이 나와 있는 상태이지만, 어떤 결론도
나지 않았습니다.
* 소스 패키지가 다루기 불편하다.
.dsc, .diff.gz, .orig.tar.gz 파일 세 개로 구성되어
있습니다.. 데비안 초창기에는 바이너리 파일이 없이 (FreeBSD
port처럼) 패치로만 구성된 시절이 있었기 때문에 그 때부터 내려온
관습입니다.
파일이 많아서 불편한 것 뿐만 아니라, 패치 내용과 관계없이 1개의
패치만 존재하는 것도 관리를 어렵게 합니다. 요즘에 패치 안에
다시 패치 여러 개를 집어 넣어서 빌드할 때 적용하는 테크닉도
이용되긴 했지만 좀 부자연스럽습니다.
* 바이너리 패키지 내에 디지탈 사인하는 방법이 없다.
소스 패키지의 .dsc 파일과 업로드할 때 .changes 파일이 사인되어
업로드되긴 합니다. 그 파일 안에는 파일의 md5sum과 사이즈가
들어 있구요. 중앙집중적인 데비안에서는 업로드할 때 사인이
체크되면 그만이라고 볼 수도 있겠지만, 미러 사이트에서 바이너리
패키지를 hole을 만들도록 바꿔치기한 다음에 사이트를 공격할 수도
있습니다. 이 때 설치하는 쪽에서는 패키지를 신뢰할 수 있는 지
검사할 수 있는 방법이 없습니다.
단지 패키징 방식만 갖고 따지자면 모르겠지만, 현존하는 패키지들에서
일어나는 많은 문제들을 따지자면 수도 없이 많습니다. RPM
패키지들의 문제점은 파일의존성 기능을 남용한다는 것--필요한
라이브러리가 들어 있는 패키지에 의존하지 않고, 라이브러리
파일에 의존하기 때문에 의존성을 해결하기 위해 뭘 설치해야
할지 알 수가 없습니다. DEB 패키지들의 문제는 설치할 때
귀찮게 자꾸 뭘 물어보곤 한다는 점이구요...
글쎄요....저는 개인적으로 데비안 과 FreeBSD가 편하던데요
글쎄요....
저는 개인적으로 데비안 과 FreeBSD가 편하던데요...
데비안은 dselect, FreeBSD는 포트가 멋지더군요...
저는 이두가지에 점수를 주고 싶네요...
최고는 모르겠고,누구 Solaris에서 패키징 해보신 분 있나요
최고는 모르겠고,
누구 Solaris에서 패키징 해보신 분 있나요 ? 한번 해보려 했는데,
으윽... 메뉴얼이 없어서 그런지... 겨우 겨우 만들었습니다.
tarball 수준 ?
비교할 만한 것은 deb, rpm 이 아닐까요...
소스레벨에서의 관리에 대한 측면에서 얘기하자면,
deb 패키징은 한번도 안해봤지만, make -f debian/rules 가
먹는 것을 보고 깜딱 놀랬었던 적이 있지요. 요즈음 안되는 것 같더군요.
(debian specific 해진 부분이 많아졌다는 얘기)
deb 은 많은 융통성을 제공하고, 좀더 유닉스적인 냄새가 나는 것
같습니다. 따라서, 복잡하고 다루기가 까다롭다고 느껴지죠.
rpm은 편리하긴 하지만, 너무 일괄적이고 융통성이 없다는게 흠...
(제가 아직 방법을 몰라서인지...) 컴파일이 완료된 후에, 바이너리만을
가지고 패키징하려 하면, 트릭을 써서 해야 합니다. 안그러면
애써 컴파일 해놓은 것을 싸그리 날려버리고 다시 컴파일을 -_-;;
rpm 4.0에서는 뭐가 달라졌는지 자세히 아시는 분 없나요 ?
make -f debian/rules 로 해보지는 않았지만,그냥 패키
make -f debian/rules 로 해보지는 않았지만,
그냥 패키지의 루트디렉토리에서 debian/rules 로
바로 실행시킬 수는 있습니다. 특히 컴파일하는데
오래걸리는 것을 할 때는 참 편리하지요.
dpkg-buildpackage 를 쓰면 처음부터 시작하던데,
그냥 rules 파일을 쓰면 옵션만 주는 것으로 중단
된 곳에서 시작할 수 있으니까요.
그리고 데비안이 레드햇보다 낳은 점은 일관성이라
고 봅니다. 패키징을 왜 하는지 곰곰히 생각해보면
이 일관성이 얼마나 큰 장점인지 알 수 있게 되겠
지요.
데비안 패키지의 단점입니다. 데비안 개발자들 사이에 이 문제를 해결
데비안 패키지의 단점입니다. 데비안 개발자들 사이에 이 문제를
해결하기 위한 여러 제안들이 나와 있는 상태이지만, 어떤 결론도
나지 않았습니다.
* 소스 패키지가 다루기 불편하다.
.dsc, .diff.gz, .orig.tar.gz 파일 세 개로 구성되어
있습니다.. 데비안 초창기에는 바이너리 파일이 없이 (FreeBSD
port처럼) 패치로만 구성된 시절이 있었기 때문에 그 때부터 내려온
관습입니다.
파일이 많아서 불편한 것 뿐만 아니라, 패치 내용과 관계없이 1개의
패치만 존재하는 것도 관리를 어렵게 합니다. 요즘에 패치 안에
다시 패치 여러 개를 집어 넣어서 빌드할 때 적용하는 테크닉도
이용되긴 했지만 좀 부자연스럽습니다.
* 바이너리 패키지 내에 디지탈 사인하는 방법이 없다.
소스 패키지의 .dsc 파일과 업로드할 때 .changes 파일이 사인되어
업로드되긴 합니다. 그 파일 안에는 파일의 md5sum과 사이즈가
들어 있구요. 중앙집중적인 데비안에서는 업로드할 때 사인이
체크되면 그만이라고 볼 수도 있겠지만, 미러 사이트에서 바이너리
패키지를 hole을 만들도록 바꿔치기한 다음에 사이트를 공격할 수도
있습니다. 이 때 설치하는 쪽에서는 패키지를 신뢰할 수 있는 지
검사할 수 있는 방법이 없습니다.
단지 패키징 방식만 갖고 따지자면 모르겠지만, 현존하는 패키지들에서
일어나는 많은 문제들을 따지자면 수도 없이 많습니다. RPM
패키지들의 문제점은 파일의존성 기능을 남용한다는 것--필요한
라이브러리가 들어 있는 패키지에 의존하지 않고, 라이브러리
파일에 의존하기 때문에 의존성을 해결하기 위해 뭘 설치해야
할지 알 수가 없습니다. DEB 패키지들의 문제는 설치할 때
귀찮게 자꾸 뭘 물어보곤 한다는 점이구요...
이제 이런 식의 토론은 지겹군요.어떤 os가 제일 좋다느니..
이제 이런 식의 토론은 지겹군요.
어떤 os가 제일 좋다느니..
어떤 프로그램이 제일 좋다느니..
리눅스 vs 윈도즈
C vs C++
KDE vs GNOME
리눅스 vs 솔라리스
내것이 좋네, 네것이 좋네 티격태격 하게 되더군요.
그러다가 중간 중간에 둘 다 좋은데 왜 싸움이냐 그냥 쓰자..
하시는 중도파도 나오고..
아무런 결론 없이 흐지부지 끝납니다.
(토론 이란게 결론을 바라고 하는 건 아닙니다만..
토론에 참여하는 사람들의 어투를 보면..
자신의 주장이 모두에게 받아들여지기를 강력히 바라는 것이 보입니다.)
이번 토론도 진행 양상이 뻔하군요..
데비안 좋아하시는 분들이 우선 이러쿵 저러쿵 데비안 패키징 시스템을
자랑하실 터이고..
가끔 레드햇 사용자가 RPM칭찬 하면서 데비안 깎아내리기도 할 것이며
난데없이 tarball 쓰시는 분들이 나와서
tarball을 써야지 고수지..하는 식으로
자신의 실력을 은근히 자랑하며 남들은 내려보는..
휴우....
토론 주제를 낸 바로 다음 글이 이렇게
판깨는(?)글이라서 글 올리신 분께 무척 죄송하긴 합니다만..
kldp에 오면서 수 많은.. '비교하는 글들'을 읽고 지친 나머지
그러는 겁니다.
특별히 나쁜 감정이 있거나 훼방놓고 싶어서는 아닙니다..^^;
그리고 이 글 이후로
이 주제에 대한 토론이 올라오지 않기를 바라는 것도 아닙니다.
결론없는 논쟁이긴 하지만, 중간중간
도움되는 상식도 많이 배웠거든요..
그리고 제가 토론을 해라 말아라..(감히!!)그럴 사람도 아니구요..
그냥 답답해서 올린 글.. 가볍게 생각해 주세요..
비교하는 글들이 많은 건 사실이지만..이렇게 비교하면서 자신이 쓰
비교하는 글들이 많은 건 사실이지만..
이렇게 비교하면서 자신이 쓰는 것이 더 우수하다고 말하는 사람들도 많지만..
하지만 이렇게 비교를 하면서 어떤 것이 더 나쁘고,,
어떤 것이 더 우수한 것인지가 나타날 것이고..
자연히 어떤 방향으로 나아갈지도 나타날 거라고 생각합니다..
물론 단지 자신이 쓰는 것이 우수하다고 생각하는 사람들의 글이 많겠지만..
그렇지 않은 정말 도움이 되는 ( 위에 창우 님이 쓰신 글처럼..) 글이 적을 수도 있겠지만..
하지만 몇 안되는 도움이 되는 글로 인해서 발전이 있다면 할 가치가 있다고 생각합니다.
뭐..
사금을 채취하는(요즘은 이런 사람 없겠죠..) 사람들도 똑같은 생각이었지 않을까요..??
금 알갱이를 찾기 위해서..
수많은 모래들을 걸러내는 노력을 아끼지 않죠..
정말 발전이 있으려면 그 정도는 감수해야한다고 생각합니다.
===============
Vas Rel Por
이런 토론을 통해 오히려 많은 공부가 되고 있습니다.제가 몰랐던, 사
이런 토론을 통해 오히려 많은 공부가 되고 있습니다.
제가 몰랐던, 사용하지 않았던 부분들에 대해서 새롭게 알수 있고 바라보는 시
각또한 달라지거든요. 여러 님들의 생각을 접할때마다 한없이 보잘것 없는 저
를 느끼게 만드는군요..흠..
==================
흠 프비 책 샀는데 빨리 읽어봐야겠당..휘리릭~~~
님의 말씀에 동감합니다.특히,깊은 생각 없이 무조건 다른 것을
님의 말씀에 동감합니다.
특히,
깊은 생각 없이 무조건 다른 것을 비난하는 내용의 굴비들..
그런 것을 보면 한편으론 댓글을 달아 주고 싶기도 하지만,
한편으론 그런 것 적어서 무얼하나 라는 생각도 듭니다.
갑자기,
그냥 제 공부나 더 하는 편이 훨씬 낫겠다는 생각이 들었습니다.
저두 동감합니다.또 여기가 linux 사이트 이다보니...여기
저두 동감합니다.
또 여기가 linux 사이트 이다보니...
여기서는 linux가 모든 것을 해결하는 만능처럼 느껴진다는 생각을
들게끔하지만...
결코 세상일이 만만치는 않죠. :)
어자피 같은 오픈소스계열 아닌가염...완벽한 사람이 없는것 처럼,
어자피 같은 오픈소스계열 아닌가염...
완벽한 사람이 없는것 처럼, 완벽한 OS는 없다고 생각 하네염.
각각의 패키지도 장점 단점이 있겠고, 자신이 자신있는 방식의 패키지 관
리 방법이 있겠고... 자신이 잘 쓰고 잘 관리하면 그게 최고이죠. :-)