Gentoo의 Chromium 패키지에 내려진 고별 선언
요약
Gentoo 유지보수자들이 복잡한 빌드 체계와 잦은 업데이트 주기로 인해 Chromium 소스 패키지의 유지보수를 중단한다고 선언했습니다. Gentoo의 강력한 사용자 정의 기능(USE 플래그)이 오히려 다양한 환경에서 정상 동작을 보장하기 어렵게 만들었으며, 지속적인 자원봉사 노력에 큰 부담으로 작용했습니다.
핵심 포인트
- Chromium 패키지는 복잡한 빌드 시스템과 잦은 업데이트로 유지보수가 어려움.
- Gentoo는 'last rites' 절차를 통해 공식적으로 유지보수 중단을 알림.
- 외부 ebuild만으로는 부족하며, 충분한 검증 시간 확보가 필수적임.
- 유지보수 지속을 위해서는 최소 3명의 담당자가 필요하다고 판단됨.
Gentoo 유지보수자들이 복잡한 빌드 체계, 빠른 릴리스 주기, 반복되는 사용자 불만 속에서 Chromium 소스 패키지의 유지보수 중단 절차 에 들어감
Gentoo의 USE 플래그 와 시스템 도구 모음 지원은 빌드 유연성을 제공하지만, 특정 환경에서 성공한 ebuild만으로는 다양한 사용자 환경의 정상 동작을 보장할 수 없음
Rust와 Go 의존성 , 불안정한 소스 배포 아카이브 생성 체계가 부담을 키웠으며, 유지보수에는 긴 컴파일 시간과 지속적인 패치 조정이 필요함
패키지를 이어받거나 나중에 복원할 수는 있지만, 유지보수자들은 지속 가능한 운영 계획 을 요구하며 최소 3명의 담당자가 필요하다고 판단함
사용자는 외부 저장소, 다른 브라우저, Flatpak 등을 선택할 수 있으나 아키텍처와 배포 주체의 제약 이 있으며, 다른 배포판도 Chromium 보안 업데이트를 따라가는 데 어려움을 겪고 있음
Gentoo의 소스 빌드 모델과 Chromium
Google Chrome의 오픈소스 업스트림인 Chromium 은 복잡한 빌드 시스템, 다수의 번들 의존성, 잦은 릴리스 때문에 오래전부터 Linux 배포판의 패키징과 빌드가 어려운 프로젝트 였음
Gentoo는 사용자가 Portage 로 소프트웨어를 소스에서 빌드하는 데 초점을 맞춤
Binhost 는 일부 소프트웨어의 사전 빌드 바이너리를 제공하지만, 소스 빌드는 USE 플래그 로 컴파일 시점의 선택권 을 제공함
선택적 라이브러리 연결이나 문서 설치 여부 등을 지정할 수 있음
Chromium의 -bundled-toolchain
은 업스트림에 포함된 Clang 대신 시스템의 Clang을 사용하도록 함
번들 도구 모음은 x86-64에만 제공되므로 이 설정은 x86-64에서는 선택 사항이지만 다른 아키텍처에서는 필수임
현재 Chromium은 독점 코덱을 포함한 빌드 문제 때문에 Gentoo 바이너리 패키지로도 제공되지 않음
유지보수 중단 선언과 누적된 갈등
Arch Linux, Debian, Fedora 등이 담당자를 잃은 패키지를 “orphan”이라고 부르는 반면, Gentoo는 “last rites ”라는 절차를 사용함
gentoo-dev-announce 메일링 리스트에 유지보수 중단을 알리고 다른 개발자가 인수할 기회를 줌
이후 Gentoo ebuild 저장소 에서 해당 ebuild를 마스킹 해 실수로 설치하는 것을 막고, 기존 사용자가 업그레이드를 시도하면 경고함
Sam James는 Roman Žilka가 제출한 버그 보고서 에서 긴 논쟁을 거친 뒤 9월 24일 Chromium의 유지보수 중단 절차를 선언 함
Žilka는 9월 9일 보고 에서 안정 버전 151.0.7922.169
에 여러 심각도에 걸쳐 알려진 취약점 602개 가 포함돼 있다고 비판함
James는 답변 에서 Chromium이 Gentoo에서 유지보수자를 가장 많이 소진시키는 패키지이며, 수년간 여러 차례 중단 직전까지 갔다고 밝힘
앞선 취약점 보고 논의 에서도 Žilka는 업데이트 절차 개선을 요구함
Matt Jolly는 답변 에서 자원봉사 팀의 지연 원인으로 빌드 실패, 버그 배정 실수로 인한 자동화 누락 , 부족한 개인 시간을 꼽고 참여를 권함
외부 ebuild의 빌드 성공만으로는 부족한 이유
Gentoo에는 추가 또는 대체 ebuild를 제공하는 외부 저장소인 오버레이 가 있음
Valenduc는 9월 18일 Chromium 153.0.8010.47
이 Arch Linux, openSUSE, SUSE, Ubuntu에는 있지만 Gentoo에는 아직 없다고 지적함
James는 제출된 패치와 ebuild가 도움이 되더라도 검증 없이 그대로 반영할 수는 없다 고 답함
유지보수자들은 아직 문제를 살펴볼 시간을 내지 못했으며, 테스트하지 않은 ebuild가 사용자 시스템에서 동작하지 않으면 다시 불만이 발생함
필요한 작업을 맡을 사람이 없다면 업데이트보다 유지보수 중단 가능성이 커진다고 밝힘
Valenduc가 Bentoo ebuild를 가져오는 일은 어렵지 않다고 하자, James는 한 환경의 성공이 모든 USE 플래그의 동작을 뜻하지 않는다 고 반박 함
Gentoo ebuild에 적용할 패치가 제출되지 않아, 담당자가 ebuild 간 차이를 비교하고 변경 내용을 역으로 파악해야 했음
Valenduc도 노트북에서 Chromium 컴파일에 15~16시간 이 걸려 모든 조합을 시험할 수 없다고 인정 함
9월 24일 Žilka가 “터무니없다” 고 반응한 직후, James는 중단 절차를 진행 함
가능한 범위의 유지보수와 선택권 축소 제안
Maciej S. Szmigiero는 빌드와 패치가 가능한 Chromium을 잃는 것은 Gentoo 데스크톱에 큰 손실이라며 가능한 범위에서 유지보수 하는 조건으로 저장소에 남길 수 있는지 질문 함
James는 이미 자원봉사로 운영한다는 설명이 받아들여지지 않았기 때문에 어렵다고 답함
다른 저장소에서 유지할 수는 있지만 직접 작업하거나 더 낮은 유지보수 기준을 받아들여야 함
Bentoo ebuild 생성은 상당 부분 자동화된 것으로 보이며, Gentoo 버전의 일부 수정 사항이 빠져 있다고 지적함
10월 24일 중단 유예 기간이 끝나기 전에 새 담당자가 인수하거나 이후 패키지를 복원할 수 있음
다만 James는 업스트림의 높은 변경 빈도와 논의 중 일부 반응이 유지보수자를 소진시키므로, 지속 가능한 계획 없이 재개하는 것을 원하지 않음
Matt Whitlock은 대부분의 USE 플래그를 없애거나 번들 라이브러리를 시스템 라이브러리로 대체하는 작업을 중단해 부담을 줄일 수 있는지 질문 함
유연성을 모두 포기하더라도 불투명한 바이너리 도구 모음 대신 소스에서 빌드 가능한 패키지를 유지할 수 있는지가 쟁점임
업스트림이 선택 기능을 끈 빌드를 시험하지 않아, 모든 옵션의 정상 동작을 유지하는 부담이 배포판 담당자에게 넘어온다고 덧붙임
언어 의존성과 소스 배포 체계의 복잡성
James는 최근 복잡성의 일부가 Rust와 Go 의존성 추가 에서 비롯됐다고 답함
Gentoo ebuild는 빌드 중 네트워크 접근을 금지하므로 Go 빌드가 네트워크 없이 진행되도록 조정해야 했음
Google 개발자들이 새 릴리스에서 깨지는 실험적 Rust 기능을 계속 사용하는 것으로 보인다고 밝힘
업스트림의 릴리스 tarball 생성 CI 도 신뢰하기 어려웠음
Gentoo 담당자가 수정 패치를 보냈지만 검토에 오래 걸렸고, 이후에도 여러 차례 다시 문제가 발생함
소스 아카이브가 생성되지 않거나 불완전하게 생성되는 상황에도 업스트림의 대응이 부족했다고 James는 평가함
지속 가능한 유지보수에 필요한 인력과 시간
Jolly의 유지보수 경험 에 따르면, 대용량 RAM을 갖춘 빠른 PC에서도 컴파일만 주당 6시간 이상 걸릴 수 있으며 64비트 Arm에서는 더 오래 걸림
패치 리베이스와 수정 사항 선별 반영, 반복 빌드, 새 버그 조사와 수정, 번들 의존성과 Gentoo 정책의 절충, 자동화 작업까지 합치면 매주 최소 근무일 하루만큼의 자유 시간을 투입해야 함
매주 수백 건의 브라우저 CVE가 나오는 환경에서 최신 버전을 유지해야 한다는 압박도 큼
극복 불가능한 기술적 장애물은 없지만, C, C++, Go, JavaScript, Rust 에 익숙한 여러 유지보수자가 필요함
다른 곳에서는 활용하기 어려운 Google 자체 도구들도 익혀야 함
Google 도구 모음을 사용하면 단순해지지만 x86-64로 지원 범위가 제한 됨
arm64, ppc64, RISC-V 오버레이 지원을 잃으면서도 상황을 실질적으로 개선하지 못한다고 Jolly는 판단함
Jolly는 새 담당자의 커밋 검토와 조언에는 참여할 의사가 있지만, 최소 3명 이 필요하다고 봄
과거 경험상 1인 유지보수는 지속되지 않았으며, 자신이 담당하기 시작한 2023년 이후 릴리스 주기가 두 차례 단축됨
Chromium의 릴리스 주기 는 stable, beta, development 등 여러 채널로 구성됨
안정 채널에서 대략 2주마다 새 주요 브랜치 , 매주 새 버전이 나옴
Gentoo 사용자의 대안과 다른 배포판의 상황
당분간 Gentoo 사용자는 다른 Chromium ebuild를 찾거나, 다른 브라우저 또는 배포 방식을 선택해야 할 것으로 보임
Flathub의 Chromium Flatpak 은 대안이지만 업스트림이 아닌 제3자가 빌드한 미검증 패키지 임
x86-64와 64비트 Arm 이외의 사용자에게는 도움이 되지 않음
업스트림 안내에 따라 직접 빌드할 수도 있지만, 안내 접근성과 빌드 과정 모두 부담이 있음
확인 당시 소스 받기 페이지 의 Linux, macOS, Windows 안내 링크는 503 오류 를 반환함
검색으로 찾을 수 있는 Linux 빌드 안내 는 날짜가 없어 최신 여부가 불명확하며, 안내가 정확하더라도 빌드 과정은 상당히 복잡함
프로젝트의 사전 빌드 바이너리 는 x86-64용만 제공됨
다른 배포판은 Chromium을 계속 제공하지만 Gentoo와 같은 유연성은 제공하지 않으며, 최신 보안 수정 반영에도 간극이 있음
Fedora 패키지 는 확인 당시 154.0.8037.92
로, 10월 1일 공개된 업스트림 154.0.8037.97
보다 한 버전 뒤처짐
Debian 보안 저장소도 같은 버전이며, 보안 추적 페이지 는 154.0.8037.97
에서 알려진 CVE 최소 11개 를 수정했음을 보여줌
Gentoo 사용자의 기대 수준을 충족할 팀이 나타날 가능성은 있지만, 그동안 Chromium 유지보수 자체가 더 쉬워질 가능성은 낮아 보임
댓글과 토론
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기