데비안 “테스트” 배포

데비안 테스팅(testing) 배포에 대한 기본적인, 사용자 지향 정보는, 데비안 FAQ를 보십시오.

일반 사용자와 테스팅 개발자 모두에게 중요한 것은, 테스팅의 보안 업데이트는 보안팀에서 다루지 않는다는 겁니다. 자세한 정보는 보안 팀 FAQ를 보십시오.

이 페이지는 데비안 개발자에게 중요한 testing 측면을 주로 다룹니다.

testing이 어떻게 동작하나

testing 배포판은 자동 생성 배포판입니다. testing 배포판은 unstable 배포판에서 스크립트 모음에 의해 생성되는데, 스크립트는 unstable에서 릴리스 크리티컬 버그가 충분히 없는 패키지를 이동해서 testing을 생성합니다. testing에서 다른 패키지들의 의존성을 언제나 만족하는 방향으로 동작합니다.

(특정 버전의) 패키지는 아래 기준을 모두 만족하면 테스팅으로 옮깁니다:

  1. 업로드 긴급성에 따라 10, 5 또는 2일 동안 unstable에 들어있어야 합니다.
  2. 이전에 unstable의 모든 아키텍처에서 컴파일 되고 최신이어야 합니다.
  3. 현재 릴리스 크리티컬 버그가 없어야 하고, testing 버전에는 해당되지 않습니다. (자세한 내용 참조.)
  4. 모든 의존성이 testing 패키지에서 이미 만족하거나, 또는 동시에 설치될 패키지 그룹에 의해 만족해야 합니다.
  5. testing에 패키지 설치하는 작업을 할 때 현재 testing의 패키지가 깨지지 않아야 합니다. (더 많은 정보)

첫 세 가지를 만족하는 패키지를 Valid Candidate라 합니다.

업데이트 스크립트는 언제 각 패키지가 unstable에서 testing으로 가는지 보여줍니다. 출력은 두 가지 입니다:

자주 묻는 질문 답변

릴리스 크리티컬 버그는 무엇이고, 어떻게 계산하나요?

어느 정도 이상 높은 심각도의 모든 버그는 현재 기본적으로 릴리스 크리티컬(release-critical)으로 취급됩니다. 그러한 버그는 critical, grave 및 serious 버그입니다.

그러한 버그는 패키지를 데비안 안정 버전에 릴리스하는데 영향을 주는 버그로 취급됩니다. 일반적으로 어떤 패키지에 해결되지 않은 릴리스 크리티컬 버그가 있다면, testing에 들어가지 않고, 결과적으로 stable에 릴리스되지 않을 것입니다.

testing 버그 개수를 세는 방법은 다음과 같습니다. 모든 릴리스 심각 버그로, 릴리스 아키텍처에 대해 testing에서 사용할 수 있는 패키지/버전 조합으로 표시된 버그의 개수입니다.

testing에 패키지를 설치하면 어떻게 다른 패키지를 망가뜨릴 수 있나요?

배포판 아카이브의 구조에서는 한 패키지는 하나의 버전만 들어있을 수 있고, 패키지는 패키지의 이름으로 정의됩니다. 그러므로, acmefoo라는 소스 패키지와 그 바이너리 패키지인 acme-foo-bin, acme-bar-bin, libacme-foo1, libacme-foo-dev 패키지를 testing에 설치할 경우, 과거 버전은 제거됩니다.

하지만, 과거 버전에서 라이브러리의 이전 soname이 들어 있는 바이너리 패키지를 (예: libacme-foo0) 제공할 수도 있습니다. acmefoo의 과거 버전을 제거하면 libacme-foo0 패키지를 제거할 것이고, 그러면 libacme-foo0 패키지에 의존하는 다른 패키지를 망가뜨립니다.

눈에 띄는 경우로, 이런 일은 버전마다 바이너리 패키지의 모음이 달라지는 패키지에 (주로 라이브러리) 주로 영향을 미칩니다. 하지만, ==, <= 또는 << 연산자가 포함된 버전 의존성이 있는 패키지에도 영향을 미칩니다.

소스 패키지가 제공하는 바이너리 패키지 모음이 이런 방식으로 변화하는 경우, 과거 바이너리에 의존하던 패키지를 새 바이너리에 의존하도록 업데이트해야 합니다. 그러한 소스 패키지를 testing에 설치하면 그 패키지에 의존하는 모든 패키지를 망가뜨리게 되고, 어느정도 노력을 기울여야 합니다. 의존하는 모든 패키지를 업데이트해 설치가 가능하도록 만들어서 망가지지 않도록 해야 합니다. 그리고, 모두 준비가 되면, 보통 릴리스 관리자나 관리자 보조의 개입이 필요합니다.

이와 같이 복잡한 패키지 모음을 다루는데 문제가 있는 경우, debian-devel 또는 debian-release 리스트에 도움을 요청하십시오 .

아직도 모르겠습니다! testing 스크립트가 말하길 이 패키지가 올바른 후보가 아니라는데, 아직 testing에 들어가지 않았어요.

이런 상황은 이 패키지의 설치가 다른 패키지를 망가뜨리는 경우로, 직접적 또는 간접적으로 일어날 수 있습니다.

패키지의 의존성을 고려하는 걸 기억하십시오. 패키지가 libtool 또는 libltdlX에 의존한다고 가정합니다. 그러면 올바른 버전의 libtool이 testing에 들어갈 때까지 여러분의 패키지도 testing에 들어가지 않습니다.

마찬가지로, libtool의 설치가 이미 testing에 있는 패키지를 망가뜨리지 않아야 testing에 들어갑니다. 다르게 말하면, libltdlY에 (여기서 Y가 예전 버전) 의존하는 모든 패키지를 다시 컴파일하고, 모든 릴리스 크리티컬 버그가 사라질 때까지는 이러한 패키지는 testing에 들어가지 않습니다.

여기에서 이 텍스트 출력[gzip 버전]이 도움이 되는 경우입니다. 이 파일에 해당 후보를 testing에 추가했을 때 어떤 패키지가 망가지는지에 대한 힌트가 (간결하긴 하지만) 있습니다. ( 더 자세한 정보는 개발자 참고서를 참고하십시오.)

왜 종종 Architecture: all 패키지가 testing에 들어가기 어려운가요?

Architecture: all 패키지를 설치하려면, 모든 아키텍처에서 그 의존성을 만족할 수 있어야 합니다. 만약 제한적인 데비안 아키텍처에서만 컴파일할 수 있는 특정 패키지에 의존한다면, 그 의존성을 만족할 수 없습니다.

그러나, 한동안 testing은 Architecture: all 패키지의 i386이 아닌 아키텍처의 설치 가능 여부를 검사하지 않을 것입니다. (보기 싫은 꼼수이고 이렇게 하는 게 만족스럽지는 않지만, 이렇게 하고 있습니다. —aj)

내 패키지는 오래돼서 어떤 아키텍처에서 중단되었습니다. 무엇을 해야 하나요?

빌드 로그 데이터베이스에서 패키지 상태를 확인하십시오. 패키지가 빌드하지 않으면, failed로 표시될 것입니다. 빌드 로그를 조사하고 패키지 소스 코드에서 발생한 문제를 바로잡으십시오.

일부 아키텍처에서 새 버전의 패키지가 빌드되었지만, testing 스크립트 출력에 나타나지 않는 경우, 좀 더 참을성을 갖고 해당 buildd 관리자가 데비안 아카이브에 파일을 업로드할 때까지 기다려야 합니다.

이전 실패에 대한 수정 사항을 업로드했음에도, 일부 아키텍처에서 패키지의 새 버전을 빌드하지 못하는 경우, 그 이유는 의존성을 기다리도록 표시되었기 (Dep-Wait) 때문일 것입니다. 확인하려면 이러한 이른바 wanna-build 상태 목록을 확인할 수 있습니다.

이러한 문제는 시간이 지나면 결국 대부분 수정되겠지만, 너무 긴 시간 동안 (예를 들어, 2주 이상) 기다렸다면, 해당 포트의 buildd 관리자에게 알리십시오. 포트 웹페이지 또는 해당 포트의 메일링 리스트를 이용하십시오.

control 파일의 아키텍처(Architecture) 목록에서 해당 아키텍처를 명시적으로 제외했고, 그 전에는 해당 아키텍처에서 패키지를 빌드했다면, testing으로 옮겨가기 전에 해당 아키텍처의 과거 바이너리 패키지를 그 아카이브에서 제거하도록 요청해야 합니다. ftp.debian.org에 대해 버그를 만들어서 제외된 아키텍처의 패키지를 unstable 아카이브에서 제거하도록 요청합니다. 일반적으로 관련 포팅 리스트에도 예의상 알려야 합니다.

예외는 없습니까? acmefoo 패키지가 모든 요구사항을 만족하지 못했는데도 testing에 들어갔습니다.

릴리스 관리자는 두 가지 방법으로 규칙을 무시할 수 있습니다:

실제적이고, 간단하지 않은 예를 제공할 수 있나요?

여기 하나의 예를 들어봅시다: 소스 패키지 apache를 testing에 설치하면, 바이너리 패키지 apache, apache-common, apache-dev 그리고 apache-doc이 같이 설치되고, 과거 버전을 제거합니다.

하지만 모든 아파치 모듈 패키지는 apache-common (>= 무언가), apache-common (<< 무언가)에 의존하므로, 이러한 변화는 모든 의존성을 망가뜨립니다. 결과적으로, 모든 아파치 모듈은 testing을 업데이트하면서 새로운 버전의 아파치에 맞춰 다시 컴파일해야 합니다.

이 문제를 좀 더 자세히 설명해 봅시다: 모든 모듈을 새로운 아파치에서 동작하도록 업데이트한 뒤에, testing 스크립트는 apache-common을 시도해 보고 모든 아파치 모듈을 망가뜨린다고 알아낼 것입니다. 왜냐하면 아파치 모듈에는 Depends: apache-common (<< 현재 버전)이라고 들어있을 것이기 때문입니다. 그리고 libapache-foo를 시도해 보고 Depends: apache-common (>=새 버전)이 들어 있어서 설치하지 못한다고 알아낼 것입니다.

그러나, 릴리스 관리자는 나중에 다른 로직을 (종종 수동 개입을 통해) 적용합니다: apache-common이 망가뜨린다는 사실을 무시하고 동작하는 부분을 계속 진행합니다. 할 수 있는 모든 일을 했는데도 동작하지 않으면, 불행하지만 나중에 언젠가는 동작할 것입니다. 나중에 임의의 libapache-foo 패키지를 시도해 보고 실제로 동작하는지 확인할 것입니다.

모든 방법을 시도한 다음, 얼마나 많은 패키지가 망가졌는지 확인하고, 본래 상태보다 나아지는지 나빠지는지를 확인하고 모두 받아들이거나 모두 무시합니다. 이 정보를 update_output.txt 파일의 recur: 줄에서 볼 수 있습니다.

예를 들어:

         recur: [foo bar] baz

위의 의미는 foo 및 bar 패키지가 상태를 더 낫게 만들 것임을 이미 확인했고, 망가지기는 하겠지만, baz를 시도해 무슨 일이 벌어지는지 확인할 것임을 뜻합니다. update_output.txt 파일에서 accepted로 시작하는 줄은 상태를 더 좋아지게 만드는 것처럼 보임을 뜻하고, skipped 줄은 상태를 더 나쁘게 만듦을 가리킵니다.

update_output.txt 파일 내용은 전혀 읽을 수 없습니다!

그건 질문이 아닙니다. ;-)

예를 들어:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

위의 의미는 cln 패키지가 testing에 들어가면, ginac-cint 및 libginac-dev 패키지가 i386의 testing에서 설치 불가능해진다는 뜻입니다. 아키텍처는 알파벳 순서로 확인하기 때문에 문제가 발견된 첫번째 아키텍처만 보일 것입니다 — 그래서 alpha 아키텍처가 자주 보입니다.

got 줄은 여러 아키텍처의 (문제가 발견되는 첫번째 아키텍처 전까지, 앞에 언급한 내용 참고) testing에서 문제가 발생한 줄번호입니다. i-45는 cln 패키지가 testing에 들어가면, i386에서 45개의 설치 불가능 패키지가 발생한다는 뜻입니다. cln 위와 아래에 나오는 항목에서 현재 43개의 설치 불가능한 패키지가 testing에 있다는 점을 알 수 있습니다.

skipped: cln (0) (150+4) 줄의 의미는 이 패키지 다음에 모든 패키지가 통과하려면 아직 150개의 패키지가 더 지나가야 된다는 뜻입니다. 그리고 4개의 패키지는 의존성을 망가뜨리기 때문에 이미 업그레이드하지 않을 계획입니다. (0)은 별로 관계가 없으니, 무시해도 무방합니다.

여기서 하나의 testing 스크립트 실행에 모든 패키지의 여러가지 검사가 이루어진 점에 주의하십시오.

Jules Bean이 자주 묻는 질문을 최초로 모았습니다.

추가 정보

다음 페이지에 testing의 현재 상태 및 unstable에서 testing으로의 패키지 이전에 대해 추가적인 정보가 들어 있습니다:

좀 더 오래된 설명 메일에 관심이 있을 수도 있습니다. 이 당시의 주요 맹점은 패키지 풀을 고려하지 않았다는 점입니다. 패키지 풀은 테스팅 스크립트 작성 뒤에 James Troup이 구현했기 때문입니다.

Anthony Towns가 테스팅 구현에 공로가 있습니다.