“Тестируемый” выпуск Debian

Простую, ориентированную на пользователей информацию о тестируемом выпуске вы можете посмотреть в ЧаВО Debian.

Обычным пользователям и разработчикам тестируемого выпуска важно знать, что обновления безопасности для тестируемого выпуска не поддерживаются командой безопасности. Дополнительную информацию смотрите в ЧаВО команды безопасности.

Эта страница в первую очередь содержит те аспекты тестируемого выпуска, которые важны для разработчиков Debian.

Как работает тестируемый выпуск

Тестируемый выпуск генерируется автоматически. Он создается из нестабильного выпуска при помощи набора сценариев, которые пытаются переместить пакеты, не имеющие, как кажется, серьезных ошибок, мешающих выпуску (release-critical bugs). Эти сценарии выполняют перемещение пакетов с учётом их зависимостей.

Пакет (конкретная версия пакета) будет перемещена в тестируемый выпуск, когда он удовлетворяет всем следующим критериям:

  1. Пакет должен находиться в нестабильном выпуске 10, 5 или 2 дня, в зависимости от срочности загрузки;
  2. Он должен быть скомпилирован и обновлён для всех архитектур, для которых он был ранее скомпилирован в нестабильном выпуске;
  3. Он не должен содержать ошибок, мешающих выпуску и которые не содержатся в версии пакета, уже находящейся в тестируемом выпуске (дополнительную информацию см. ниже);
  4. Все его зависимости либо должны быть удовлетворены пакетами, уже находящимися в тестируемом выпуске, либо должны удовлетворяться группой пакетов, которые устанавливаются одновременно с ним;
  5. Операция установки пакета в тестируемый выпуск не должна ломать какие-либо пакеты, уже находящиеся в тестируемом выпуске. (дополнительную информацию см. ниже.)

Пакет, удовлетворяющий первым трём условиям из обозначенных выше, называется Годным кандидатом (Valid Candidate).

Сценарий обновления показывает, когда каждый пакет может быть перемещен из нестабильного выпуска в тестируемый. Сценарий предоставляет два вывода:

Часто задаваемые вопросы (с ответами)

Что такое ошибки, мешающие выпуску (release-critical bugs), и как они подсчитываются?

Все ошибки с высокой важностью по умолчанию считаются ошибками, мешающими выпуску; в настоящее время это ошибки с важностью critical, grave и serious.

Предполагается, что эти ошибки оказывают влияние на шансы пакета войти в стабильный выпуск Debian: вообще, если пакет содержит открытые ошибки, мешающие выпуску, он не попадет в тестируемый выпуск и, следовательно, не будет выпущен в составе стабильного выпуска.

Количество ошибок в тестируемом выпуске представляет собой все ошибки, мешающие выпуску, которые отмечены как применимые к комбинациям пакет/версия, доступным в тестируемом выпуске для выпускаемой архитектуры.

Как установка пакета в тестируемый выпуск может сломать другие пакеты?

Структура архивов выпуска такова, что они могут содержать только одну версию пакета; пакет, определяется его именем. Поэтому когда пакет с исходным кодом acmefoo устанавливается в тестируемый выпуск вместе со своими двоичными пакетами acme-foo-bin, acme-bar-bin, libacme-foo1 и libacme-foo-dev, то старая версия удаляется.

Тем не менее, старые версии могут предоставлять двоичный пакет со старой библиотекой с тем же именем, как например libacme-foo0. Удаление старого acmefoo удалит libacme-foo0, что сломает все пакеты, зависящие от этого пакета.

Очевидно, это в первую очередь оказывает влияние на пакеты, предоставляющие изменение набора двоичных пакетов разных версий (в основном библиотек). Тем не менее, это также оказывает влияние на пакеты, у которых зависимости по версии объявлены как ==, <= или <<.

Когда набор двоичных пакетов, предоставляемый пакетом с исходным кодом, изменяется указанным образом, все пакеты, зависящие от старых двоичных файлов, должны быть обновлены так, чтобы они зависели от новых двоичных файлов. Так как установка такого пакета с исходным кодом в тестируемый выпуск ломает все пакеты, зависящие от него в тестируемом выпуске, следует быть осторожным: все зависящие пакеты должны быть обновлены и готовы для установки, чтобы они не были сломаны, и, когда всё готово, обычно требуется вмешательство менеджера выпуска или его ассистента.

Если вы испытываете проблемы со сложными группами пакетов, для помощи свяжитесь с debian-devel или debian-release.

Я всё ещё не понимаю! Сценарии тестируемого выпуска говорят, что этот пакет является годным кандидатом, но он всё ещё не попал в тестируемый выпуск.

Скорее всего это происходит потому, что когда пакет устанавливается, напрямую или не напрямую, он сломает некоторые другие пакеты.

Проверьте зависимости вашего пакета. Допустим ваш пакет зависит от libtool или от libltdlX. Ваш пакет не может войти в тестируемый выпуск, пока нужная версия libtool не будет готова войти в него.

В свою очередь, это не произойдёт пока установка libtool будет ломать пакеты, уже находящиеся в тестируемом выпуске. Другими словами, пока все другие пакеты, которые зависят от libltdlY (где Y является более ранней версией) не будут перекомпилированы, и все их ошибки, мешающие выпуску, не будут закрыты и т.д., ни один из эти пакетов не войдёт в тестируемый выпуск.

Вот когда текстовый вывод [в формате gzip] оказывается полезен: он даёт подсказки (хотя и очень краткие) о том, какие пакеты ломаются, когда годный кандидат добавляется в тестируемый выпуск (подробная информация в справочнике разработчика).

Почему иногда трудно добавить пакеты с Архитектура: all в тестируемый выпуск?

Если должен быть установлен пакет с Архитектура: all, его зависимости должны удовлетворяться на всех архитектурах. Если он зависит от определённых пакетов, которые компилируются только на ограниченном наборе архитектур Debian, то его зависимости не могут быть удовлетворены.

Тем не менее, в данное время тестируемый выпуск игнорирует возможность установки пакетов с Архитектура:all на не-i386 архитектуры. (Это серьезный хак и я не то, чтобы рад, сделать это, но вот пожалуйста. —aj)

Мой пакет застрял, так как он устарел на некоторых архитектурах. Что мне делать?

Проверьте статус вашего пакета в базе данных журналов сборки. Если пакет не собран, он будет отмечен как провалившийся (failed); исследуйте журналы сборки и исправьте проблемы, вызванные исходным кодом вашего пакета.

Если вы заметили, что для некоторых архитектур новая версия вашего пакета собралась, но он всё ещё не показывается в выводе сценарием тестируемого выпуска, то вам следует немного потерпеть пока соответствующий buildd-сопровождающий не загрузит файлы в архив Debian.

Если вы заметили, что для некоторых архитектур ваша новая версия пакета вообще не собиралась, несмотря на тот факт, что вы загрузили исправление для более ранней неудачной сборки, причина, вероятнее всего, состоит в том, что пакет отмечен как ожидающий зависимости (Dep-Wait). Для верности вы также можете посмотреть список этих так называемы wanna-build состояний.

Эти проблемы обычно в конце концов исправляются, но если вы ждёте уже большой промежуток времени (например, две недели или больше), уведомите соответствующего сопровождающего переноса buildd, если он указан на веб-странице переноса, или напишите в список рассылки этого переноса.

Если вы явным образом исключили какую-то архитектуру из списка Architecture в управляющем файле (control file), а пакет уже был собран для этой архитектуры ранее, вам нужно запросить удаление старого двоичного пакета для этой архитектуры из архива до того, как ваш пакет сможет перейти в тестируемый выпуск. Вам следует отправить отчёт об ошибке в ftp.debian.org, запрашивая удаление пакетов исключённой архитектуры из нестабильного архива. Как правило, в целях этикета следует уведомить список рассылки соответствующего переноса.

Есть ли исключения? Я уверен, что acmefoo попал в тестируемый выпуск, хотя он не удовлетворяет всем требованиям.

Менеджеры выпуска могут отменять эти правила двумя способами:

Покажите реальный, нетривиальный пример

Вот он: когда пакет с исходным кодом apache устанавливается в тестируемый выпуск вместе со своими двоичными пакетами apache, apache-common, apache-dev и apache-doc, старая версия удаляется.

Тем не менее, все пакеты с модулями Apache зависят от apache-common (>= что-то), apache-common (<< что-то), поэтому это изменение сломает все эти зависимости. Следовательно, все модули Apache должны быть перекомпилированы с новой версией Apache для того, чтобы тестируемый выпуск был обновлён.

Давайте рассмотрим это более тщательно: после того как все модули будут обновлены в нестабильном выпуске так, чтобы они работали с новой версией Apache, сценарии тестируемого проверят пакет apache-common и обнаружат, что он ломает все модули Apache, поскольку они имеют параметр Зависит: apache-common (<< текущая версия), и затем проверят libapache-foo и обнаружат, что он не устанавливается, поскольку имеет параметр Зависит: 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 войдёт в тестируемый выпуск, то ginac-cint и libginac-dev станут неустанавливаемыми в тестируемом выпуске на i386. Заметьте, что архитектуры проверяются в алфавитном порядке и показываются только проблемы первой архитектуры — вот почему чаще всего показывается архитектура alpha.

Строки с got содержат количество проблем в тестируемом выпуске на разных архитектурах (до первой архитектуры, где найдена проблема — см. выше). i-45 означает, что если бы cln вошёл в тестируемый выпуск, в выпуске было бы 45 неустанавливаемых пакетов на i386. Некоторые из пунктов, приведённых над и под cln, показывают, что 43 пакета были неустанавливаемыми в тестируемом выпуске на i386 в это время.

Строка skipped: cln (0) (150+4) означает, что остаётся 150 пакетов, которые следует проверить, чтобы проверка всех пакетов была завершена, и что 4 пакета уже не планируются для обновления, так как они будут ломать зависимости. Число (0) не важно, вы можете его игнорировать.

Заметьте, что проводится несколько проверок всех пакетов в одном запуске сценария тестируемого выпуска.

Изначально часто задаваемые вопросы и ответы на них собрал Жиль Бьян (Jules Bean).

Дополнительная информация

Следующие страницы содержат дополнительную информацию о текущем состоянии тестируемого выпуска и миграции пакетов из нестабильного выпуска в тестируемый:

Также вам может быть интересно прочитать старое письмо с объяснением. Его единственный главный недостаток в том, что в нём не учитывается пул пакетов, так как он был реализован Джеймсом Троупом (James Troup) после того, как было написано письмо.

Тестирующий код доступен с ftp-master.

За реализацию тестирования благодарим Энтони Тоунса (Anthony Towns).