unstable에서 패키지 하나만 가져온다

관리용 컨테이너에 특정 버전의 데이터베이스 클라이언트를 넣어야 했다. 기반 이미지는 최신 배포판인데 그 버전은 벤더 저장소에서 가져와야 하는 상황이었다.

Open Table of contents

없는 계열과 안 맞는 라이브러리

벤더 저장소의 배포판 계열 목록을 확인하니 최신 계열이 아예 없었고 바로 이전 안정 계열도 요청하면 응답이 없었다. 그보다 더 옛날 계열에는 원하는 최신 패치 버전이 있어서 설치를 시도했다.

그런데 그 계열 패키지는 옛 라이브러리 계열로 빌드돼 있고 기반 이미지에는 새 라이브러리만 있어서 설치가 깨졌다. 결국 남은 것이 불안정 계열이었고 버전은 조금 낮지만 새 라이브러리로 빌드돼 있어 호환됐다.

불안정 계열을 쓴다고 했더니 왜 그것을 쓰느냐와 바로 이전 안정 계열을 찾아보라는 지적이 왔다. 이름 그대로 불안정하므로 맞는 지적이었다.

찾아봤다고 말로 답하는 대신 일회용 컨테이너로 각 계열을 실제로 시도해 결과를 붙였다. 한쪽은 저장소 자체가 없고 다른 쪽은 저장소는 있으나 설치 시 라이브러리가 안 맞는다는 것을 실측 결과로 보이고 나서야 배제가 근거를 가졌다.

불안정 계열을 쓰되 그것이 시스템 전체로 번지면 안 됐다. 그래서 핀을 걸었는데 대상을 계열이 아니라 출처로 잡았다.

계열로 걸면 그 계열의 모든 패키지가 우선돼 시스템 라이브러리까지 불안정 계열 것이 온다. 출처로 걸면 그 저장소에서 오는 패키지만 우선되므로 데이터베이스 클라이언트만 그쪽에서 오고 나머지는 기반 저장소 것을 쓴다.

기반 이미지를 옛 배포판으로 내리는 대안도 있었고 그러면 그 계열의 최신 버전을 그대로 쓸 수 있었다. 그렇게 하지 않았다.

이 컨테이너에는 다른 도구들도 들어 있어서 기반을 내리면 그것들이 전부 영향을 받는다. 하나를 위해 전부를 희생하는 것이므로 영향 범위가 큰 쪽은 안 건드리기로 했다.

최종 결정을 채택한 것과 그 이유와 비용과 배제한 것과 그 이유로 나눠 기록했다. 불안정 계열에 출처 한정 핀을 건 것을 채택하고 기반 이미지 교체는 영향 범위 때문에 배제했다.

버전이 조금 낮다는 비용도 함께 적었다. 왜 불안정 계열을 썼느냐는 질문에 대한 답이 문서에 있으므로 같은 지적이 다시 와도 그 문서를 보면 된다.