- Debian의 독특한 관행은 30년 된 대규모 범용 운영체제가 품질, 보안, 자유 소프트웨어 원칙을 오래 유지하기 위해 쌓아온 선택에서 나옴
- 특정 용도 배포판이 아니라 대부분의 사람과 목적에 맞는 범용 배포판을 지향하며, 패키지 포함 여부는 자유 소프트웨어성과 유지 품질이 핵심 기준임
- 헌법, 사회계약, DFSG는 초기의 느슨한 운영이 한계를 드러낸 뒤 생긴 장치로, 민주적 의사결정과 제한된 리더 권한을 제도화함
- 자체 포함 빌드와 번들 라이브러리 회피는 외부 저장소나 중복 의존성에 휘둘리지 않고 긴급 보안 수정, 재빌드, 새 아키텍처 이식을 가능하게 하는 유지보수 전략임
- 회원 심사, 릴리스 코드명, 느린 변화 속도는 수천 개 패키지와 수천만 대 설치 기반을 가진 프로젝트가 신뢰, 미러링 비용, 합의 비용을 관리하는 방식임
Debian이 지향하는 운영체제
- Debian은 고품질, 보안, 범용성을 갖춘 운영체제를 지향하며, 활발히 쓰이는 대부분의 컴퓨터에서 동작하는 자유·오픈소스 소프트웨어만으로 구성되기를 원함
- 범용 운영체제라는 목표는 Debian이 대부분의 사람에게 대부분의 목적에서 적합해야 한다는 뜻임
- 모든 상황에 맞을 수는 없지만, 지향점으로 삼을 만한 목표임
- 데스크톱, 서버, 게임, 과학 연구처럼 특정 목적에 집중하는 배포판과는 다른 결정을 낳음
- 패키징 여부는 소프트웨어의 용도보다 다음 기준에 더 크게 좌우됨
- 소프트웨어가 자유 소프트웨어인지
- Debian이 고품질 패키지로 유지할 수 있는지
헌법과 거버넌스
- Debian은 명시적으로 민주적인 오픈소스 조직에 가까움
- 의사결정 절차가 잘 정의돼 있음
- 매년 Debian Project Leader를 선출함
- 프로젝트 리더 권한은 엄격히 제한되며, 일반적으로 리더십과 연결되는 많은 권한이 다른 사람에게 명시적으로 위임됨
- 초기 Debian Project Leader들은 스스로 물러나기 전까지 사실상 전권을 가진 독재자에 가까웠음
- 한 프로젝트 리더가 선을 넘은 뒤 반발로 물러났고, 그 결과 민주주의가 도입됨
- Debian은 공식 헌법으로 프로젝트 규칙을 정의함
- 현재의 규칙 체계는 역사 초기에 더 적은 규칙과 더 적은 관료제가 Debian에서 잘 작동하지 않았던 경험에서 비롯됨
사회계약과 Debian Free Software Guidelines
- 1990년대 중반에는 “open source”라는 용어가 도입되기 전이었고, “free software”는 Free Software Foundation이 정의했지만 해석 여지가 많았음
- Debian은 더 명확한 규칙을 원해 Debian Free Software Guidelines(DFSG) 를 만들었고, 이를 사회계약의 일부로 삼음
- 사회계약은 Debian이 스스로와 세계에 대해 무엇이고 무엇을 하는지 약속하는 기반 문서임
- DFSG는 그 일부임
- Debian 헌법은 사회계약을 의도적으로 바꾸기 어렵게 만듦
- 더 세부적인 규칙은 Debian이 무엇을 받아들일지 명확하게 만들고 관련 논의를 단순화함
- DFSG는 나중에 Open Source Definition의 기반이 됨
자체 포함 빌드 원칙
- Debian은 자체 포함(self-contained) 원칙을 고집함
- Debian이 패키징한 모든 것은 Debian 안의 의존성만 사용해 빌드돼야 함
- Debian 안의 모든 것은 Debian이 직접 빌드해야 함
- 이 원칙은 추가 작업을 많이 만들 수 있음
- 현재의 프로그래밍 언어 도구들은 빌드 시점에 온라인 저장소에서 의존성을 내려받는 방식을 가정하는 경우가 많음
- Debian에서는 그런 방식이 허용되지 않음
- 핵심 이유는 외부 의존성이 나중에 사라질 수 있기 때문임
- Debian은 서드파티 패키지 저장소를 통제하지 않음
- 패키지나 저장소 전체가 사라지면 Debian이 해당 패키지를 다시 빌드하지 못할 수 있음
- 새 컴파일러 업그레이드, 보안 문제 수정, 새 아키텍처 이식, 버그 수정 반영에는 재빌드가 필요함
- 자체 포함이 아니면 긴급 보안 수정 시점에 수만 개 패키지와 그 의존성이 모두 사용 가능해야 하므로, Debian은 모든 의존성을 패키징하는 쪽을 선택함
번들 라이브러리를 피하는 이유
- Debian은 패키징 대상 소프트웨어에 포함된 라이브러리 복사본이나 기타 의존성 복사본 사용을 피함
- 많은 업스트림 프로젝트는 의존성을 함께 묶거나 vendor 처리하는 편을 더 쉽게 여김
- Debian 입장에서는 인기 라이브러리의 복사본이 여러 개 생길 수 있음
- 해당 라이브러리에 보안 문제나 심각한 문제가 생기면 모든 복사본을 찾아 고쳐야 함
- 긴급 보안 문제에서는 이 작업이 귀중한 시간을 낭비하게 만듦
- zlib 사례에서 Debian은 아카이브 안에 번들된 zlib 복사본 수십 개를 발견했고, Debian 패키지들이 Debian에 패키징된 zlib 버전만 쓰게 만드는 데 상당한 노력을 들임
- 그래서 Debian은 긴급 상황이 오기 전에 패키징 단계에서 미리 작업해, Debian 안의 패키지가 Debian에 패키징된 라이브러리 버전을 쓰게 함
- 업스트림 개발자는 자신들이 검증한 번들 버전만 다루고 싶어하는 경우가 있어, 이 방식은 때때로 Debian과 마찰을 낳음
회원 심사 과정
- Debian은 운영체제로서 규모와 복잡성이 크고 널리 사용되기 때문에 구성원을 신뢰해야 함
- 특히 새 패키지를 업로드하는 사람에 대한 신뢰가 중요함
- 1990년대 Linux의 기술적 한계 때문에 모든 Debian 패키지는 설치 과정에서 전체 root 접근 권한을 가짐
- 모든 Debian 개발자는 잠재적으로 Debian이 실행되는 어떤 머신에서든 root 사용자가 될 수 있음
- Debian이 수천만 대의 머신에서 실행된다는 점에서 이는 큰 권한임
- 새 구성원은 여러 방식으로 검증됨
- 이상적으로는 Debian 개발 커뮤니티에 충분히 오래 참여해 다른 사람들에게 알려져 있어야 함
- 커뮤니티 안에서 신뢰를 쌓아야 함
- 이 과정은 Debian에 참여하려는 사람, 특히 더 작은 오픈소스 프로젝트에 익숙한 사람에게 꽤 답답할 수 있음
릴리스 코드명
- Debian은 각 주요 릴리스에 코드명을 붙임
- 이 관행은 원래 Debian 패키지 아카이브 미러링 비용을 낮추기 위해 생김
- 1990년대 중반 Debian 1.0 릴리스를 준비할 때는 코드명을 쓰지 않고 버전명으로 디렉터리를 만들었음
- 새 릴리스 개발에는 시간이 걸리므로 “1.0” 디렉터리가 미리 만들어짐
- 한 CD-ROM 출판사가 Debian 1.0이 완성되기 전에 “1.0”이라고 표시한 디스크를 조기 대량 생산함
- 그 결과 Debian 1.0 CD-ROM을 받은 사람들은 실제 1.0이 아닌 것을 받게 됨
- 단순한 해결책은 “1.0-not-released” 같은 디렉터리에서 준비한 뒤 릴리스 완료 후 “1.0”으로 이름을 바꾸는 것이었음
- 하지만 디렉터리 이름이 바뀌면 모든 미러가 릴리스를 다시 내려받아야 했고, 당시 Debian 규모에서는 비용이 컸음
- 당시 규모는 “수백 개 패키지”와 “수십 MB” 수준이었음
- 이후 Debian 아카이브에는 pool 구조가 추가됨
- 모든 릴리스의 파일이 같은 디렉터리 트리에 있고, 메타데이터 파일이 각 릴리스에 속한 파일을 지정함
- 이 구조는 미러링을 더 쉽게 만듦
- 현재는 코드명을 버리고 버전만 쓰는 것도 가능할 수 있지만, Debian이 관심을 가질지는 알 수 없음
Debian이 천천히 변하는 이유
- Debian은 매우 큰 프로젝트이며, 큰 프로젝트는 천천히 변함
- 많은 패키지에 영향을 주는 변화는 수백 명의 자원봉사자가 작업해야 할 수 있어 빠르게 진행되기 어려움
- 일부 작업은 소수의 사람이 처리할 수 있고, Debian에는 이를 가능하게 하는 절차가 있음
- 예로 GNU C compiler의 새 버전이 업로드되면, 다른 패키지에서 필요한 수정 사항을 찾는 작업은 보통 소수의 사람이 할 수 있음
- 변화가 오래 걸리는 이유는 합의 형성이 필요하기 때문이기도 함
- 합의에는 광범위한 논의가 필요함
- 이런 논의는 시간이 걸리고, 드물게만 단축될 수 있음
- Debian 개발자들은 기술적 결정에서 보수적인 편임
- 대규모 변경을 요구하지 않는 해법을 선호하는 경우가 많음