Git based distro (package management system).
글쓴이: 마잇 / 작성시간: 월, 2010/03/29 - 10:10오전
개인 설정 파일들을 백업하고 여러 배포본을 자유롭게 설치해 보기 위해서 git에 관심을 가지게 되었습니다.
http://book.git-scm.com/
http://progit.org/book/
두 책의 전부는 아니고 대부분을 읽어 봤는데요. 분산 버전 관리라는게 상당히 효율적이고 응용범위가 넓은 프로그램(개념?)이라는 생각이 들었습니다. 그러다 문득 든 생각이 배포본의 패키지 관리에 git을 쓰면 어떻게 될까 하는데까지 생각이 미치더군요.
git branch * master-gnome-desktop git pull master-gnome-desktop [update all package] git branch search vim* vim-tiny vim-full vim-gtk vim-gnome ... git merge origin/vim-full [install vim-full package ...] git reset --hard [rollback] git branch my_custom_package [make branch for install package that not in official repo] git checkout my_custom_package [install custom package or modify official package] git merge origin/master-gnome-desktop [merge official update to local custom branch] git push my_custom_package somewhere... [share customize with other]
이런식으로 사용하도록 하면 좀 더 효율적인 패키지 관리가 가능할까요?
일단 처음 설치시야 그렇다 치고 업데이트 할 때마다 변화된 내용만이 아닌 중복되는 내용을 전부 포함한 패키지 파일을 다운로드 하는 단점도 좀 보완할수 있을것 같다는 생각이 듭니다. 사실 이게 git을 기반으로 한 패키지 관리를 생각하게 한 원인이었는데요. 기술적인 기반 지식이 부족해 바이너리 파일을 많이 포함하는 패키지 관리에도 효율적일지는 잘 모르겠습니다.
또한 배포본 개발에 참여하는 독립 개발자들에게 좀 더 편안한 개발 흐름을 제공하지 않을까 하는 생각도 듭니다.
Forums:
일단 각
일단 각 프로젝트에서 관리하는 소스들은 VCS들을 많이 사용하고 있을테니 논외로 하고
배포본에서 관리하는 패키지들에 대해서만 생각을 해보면요.
사실 VCS들은 '과거의 내용'이 중요하다는 전제 하에 의미가 있습니다.
그러나 보통의 유저들에게는 새 패키지이 중요하지 과거의 패키지들은 중요하지 않죠.
따라서 패키지 서버들이 굳이 O(patch size)나 되는 부담을 떠안지 않고
O(package size) 정도의 부담만으로 최근의 패키지들만 안고 있는 경우가 일반적으로는 나을 것 같습니다.
패키지 서버 쪽이나 패키지 매니저의 부담을 줄이고 유저가 일부를 떠안는 것이죠.
( 요샌 네트워크가 꽤 빠르지 않습니까. >_< )
또한 VCS를 하나 더 둔다는 것은 실제 개발 사이트와 중복이 된다는 의미도 있습니다.
패키지 리스트의 경우는 말씀하신 대로 patch를 적용하고 있는 경우들이 있는 것으로 압니다.
데비안의 경우 패키지 리스트를 업데이트할 때 전체 레포지토리의 리스트가 아니라 patch들을 받아오죠.
( 뭐 처음에는 전체 것을 가져오겠습니다만 .. )
다신 한 번 생각을
다신 한 번 생각을 정리해 봤습니다.
사용자 측의 이점
이론상 원하는 어느 시점의 상태로든 복구가 가능 합니다. 이런 복구가 필요한 경우를 좀 생각해 볼까요.
가령 GNOME 2.28 -> 3.0으로 업그레이드를 한다거나 KDE 3.x -> KDE 4.x 업그레이드 같은 경우는 적어도 제 경험에 의하면 매끄럽게 진행되지 않는 경우가 종종 있습니다. 배포본 자체의 메이저 버전 업그레이드도 그렇겠죠. 우분투 9.10 -> 10.04, 페도라 12 -> 13 등등. 이런 정도의 거대 패키지(들)의 업그레이드를 한 경우 원상태로 되돌리기란 거의 불가능한 걸로 알고 있습니다. 잘못된 경우 보통 재설치를 선택합니다.
이렇게 큼직한 패키지들의 메이저 버전 업그레이드시에는 아직 완성도가 낮기 때문에 필연적으로 생기는 버그들이나 아니면 단순히 새로운 환경이 사용자의 기존 습관에 맞지 않기 때문에 생기는 문제들이 꽤 있습니다. 물론 간단한 한두가지 패키지의 업그레이드도 기존에 문제 없던 사용환경에 문제를 일으킬수 있습니다. 새 패키지의 버그이기 때문이기도 하고 아니면 새롭게 바뀐 인터페이스나 기능이 맘에 들지 않기 때문일수도 있겠습니다.
저는 며칠전까지 6개월 이상 우분투 9.10을 설치하고 이상없이 잘 사용해오고 있었습니다. 그러다 갑자기 KDE를 사용해보고 싶다는 생각이 들더군요. 쿠분투를 설치하거나 kubuntu-desktop 패키지를 설치해야 가능하겠죠. 사실 저는 새로운 배포본 설치 용도로 8G 크기의 빈 파티션을 잡아놓은지라 쿠분투 이미지를 받아서 새로 설치하는 것도 크게 번거로운 일은 아닙니다. 그러나 이 경우는 사실 별도의 배포본 설치가 아니라 kubuntu-desktop 패키지를 설치하는 것만으로도 가능합니다.
그러나 kubuntu-desktop 패키지 같이 큼직한 놈을 설치후 이상이 생겼을 때 깔끔하게 원상복구 시킬수가 있을까 하는 걱정이 좀 들더군요. 패키지 관리자들도 심혈을 기울여 시험을 해봤겠지만 늘 현실이 그러하듯 항상 잘 되지는 않습니다. 결국 쿠분투 받아서 별도의 파티션에 새로 설치.
얼마전에 우분투 새버전 10.04의 베타 버전이 나왔습니다. 이것도 설치해보고 싶은 마음이 무럭무럭 피어오릅니다. 현재 사용중인 시스템을 dist-upgrade 해볼 깡은 없는 지라 이것도 역시 새 배포본 설치용 빈 파티션에 설치해보고 말았습니다. 이왕 시작 한 김에 주분투 10.04도 깔아보고 맘에 들어서 현재 주분투에서 글 작성 중입니다.
배포본 이미지 받아서 굽고 재부팅 후 설치하고 이것 저것 프로그램 깔아서 설정 잡아보고 다시 원래 쓰던 배포본으로 복귀해서 그럽 부트로더 설정 다시 복구하고 ... 하는 일련의 과정들이 사실 만만하지는 않습니다. 아무리 쉽다 쉽다 해도 시간 꽤 잡아먹습니다. 리눅스 접한지 얼마 안되는 분들에게는 파티션 작업이나 부트로더 작업이 꽤 위험하기도 합니다.
그래서 이런 작업에 git이 개입한다면 어떻게 될까 생각해 보게 되었습니다.
기존의 패키지 관리자들이 제공하는 remove 기능 보다는 보다 깔끔하고 빠른 롤백이 가능하지 않나 생각이 됩니다. 또한 대부분의 배포본이 메이저 업그레이드를 되돌릴수 있는 방법이 공식적으로 없는 걸로 알고 있는데 git을 적용하게 되면 이런게 손쉽게 가능하지 않을까 생각이 됩니다.
배포본 저장소 서버나 사용자의 컴퓨터의 자원과 네트웍 자원을 더 효율적으로 소모하는 아니냐는 솔직히 제가 기술적인 지식이 없어서 잘 모르겠네요. 변화된 부분만을 받아오기 때문에 기존에 설치되어 있는 패키지들의 업데이트때 네트웍 자원을 좀 덜 소모할것 같다는 짐작만 해봅니다.
배포본 개발에 참여하는 개발자, 공헌자들간의 보다 쉬운 의사소통
사실 저는 개발 경험이 전무하고 패키지를 만들어 배포한다거나 패치를 만들어 원 저자에게 보낸다거나 해본일이 없는지라 다음에 상상하는 내용이 크게 실효성이 있는지는 경험이 있는 분들이 판단해 주시면 좋겠습니다.
배포본 개발에 공헌하는 개발자(참여자)들을 배포본 주 저장소에 저장되는 패키지들의 업데이트에 공식적인 권한이 있느냐 없느냐의 관점으로 두 부류로 나눠보겠습니다. 호칭은 임의로 붙여봤습니다.
요새 배포본들의 개발 흐름을 보면 PPA 같은 독립 개발자를 위한 저장소 지원과 이런 저장소를 사용자들이 쉽게 자신의 환경에 적용해서 설치해볼수 있게 하는게 중요한 전략으로 받아들여지고 있고 이미 널리 사용중입니다.
공식 개발자들로만은 벅찬 수많은 패키지들의 새 버전 패키징, 테스트, 추가등의 작업 부담을 덜어주고, 특정 패키지의 경우는 공식 버전으로 만족할 수 없는 사용자들의 가려운 곳을 빨리 긁어줄 수 있다는 점에서 매우 좋은 개발 방식이라고 생각됩니다.
git이 자랑하는 장점중의 하나가 - 제일 크다고 해야겠죠 - 분산 버전 관리 시스템이라는 점인데 이 장점에 대해서 알면 알수록 이러한 배포본 개발 흐름에 잘 들어맞지 않나 하는 생각이 듭니다. 분산 버전 관리 시스템의 장점 - git을 도입함으로서 이런 개발 흐름을 좀 더 장려하고 새로운 독립 개발자들의 진입 장벽을 낮추게 되지 않을까 하는 생각입니다.
git 기반의 소스 호스팅을 하는 곳 중에서 github.com이 상당히 유명한데요. 자신의 프로젝트를 올려서 개발을 공유하거나 다른 사용자의 프로젝트를 fork해서 수정하고 그걸 다시 원 저자에게 되돌려주는 흐름이 매우 직관적이고 투명하다는 생각을 했습니다.
뭐 이부분에 대해서는 더 이상의 경험이 없는지라 이만 줄여야 겠네요.
-- 마잇
--
마잇