Gentoo, Chromium 패키지에 last rites 선언하고 유지보수 중단

Gentoo 처음 써본 게 20년 전쯤인데 밤에 설치 걸어두면 아침에도 빌드 중이더라. 결국 우분투로 넘어갔음.

나는 15~20년 정도 메인 머신으로 썼음. 실행 속도보다 시스템을 내가 통제한다는 느낌이 제일 좋았는데, 시스템 상태가 자주 깨져서 재설치하는 일이 많았음.

2007년부터 데일리로 쓰는 중임. 포티지랑 USE 플래그 조합의 유연함이 아직도 제일 큰 이유임. 우분투는 쓸데없는 게 너무 많음.

나는 머신 4대에 Gentoo 깔아서 씀. /etc/portage/patches/ 에 패치만 넣으면 커널까지 설치 전에 패치되는 게 제일 편함. systemd랑 dbus는 USE 플래그로 아예 빼버렸고, 한 머신은 udev도 없음.

컴파일러 플래그로 속도 올린다는 건 옛날 얘기인 듯함. 요즘은 Firefox가 인텔 GPU 하드웨어 인코더를 안 써서 CPU로 디코딩하던 걸 설정이랑 환경변수로 고친 게 배터리랑 성능에 더 효과 있었음.

Chromium 빌드는 5년 전에도 엄청 오래 걸렸음. 나는 Rust 실험을 시작하면서 Debian으로 옮겼고, 요즘은 Rust 확장까지 붙어서 더 답이 없을 것 같음.

ccache는 안 써봤음? Chromium 재빌드할 때 체감 차이가 꽤 큼.

AI로 패키지 관리하면 되지 않냐는 얘기 있는데, Gentoo도 AI 정책 문서를 따로 만들어둔 상태임.

문제는 USE 플래그 조합이 너무 많아서 전부 빌드하는 데 시간이 오래 걸린다는 거임. 사용자들이 빨리 안 고친다고 불만 올리는 것도 관리자 지치게 하는 원인이고. AI가 이걸 어떻게 도와준다는 건지 모르겠음.

LFS로 시스템 몇 개 굴렸는데 Chromium은 차원이 다름. ninja 버전을 맞춰야 하고, clang은 pre-release 버전이 필요할 때도 있고, gcc로는 아예 안 됨. 업데이트할 때마다 ICU 바뀌면 harfbuzz, ffmpeg 다 다시 빌드해야 함.

Chromium은 엔지니어들이 앱이 잘 돌아가게 만드는 것만 우선시한 빌드 시스템이라서, 배포판 패키저 입장에서 편하게 만들 생각은 애초에 없었을 거임. OBS도 번들 라이브러리 때문에 배포판이 깨진 패키지를 내는 것처럼 비슷한 문제가 있음.