path: root/russian/devel/buildd/wanna-build-states.wml

#use wml::debian::template title="Состояния wanna-build: объяснение" BARETITLE="true"
#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="Lev Lamberov"

    <p>На этой странице объясняется значение каждого состояния wanna-build и
      то, что произойдёт с пакетом, если он находится в этом состоянии. Целевой
      аудиторией настоящего документа являются сопровождающие пакетов Debian, которые пытаются
      понять, почему их пакет был или не был собран для какой-то
      конкретной архитектуры. Кроме того, в документе даётся объяснение различных
      результатов журнала сборки.</p>

    <p>Также <a href="#graphlink">доступна</a>
      диаграмма состояний wanna-build, но заметьте, что она не сообщает всего того,
      о чём говорится в этом документе.</p>

<h2>Состояния wanna-build</h2>
<p>Для каждой поддерживаемой в Debian архитектуры существует база данных wanna-build
на buildd.debian.org, которая содержит все пакеты и их текущее
состояние компиляции. Существует 8 состояний: <em>needs-build</em>,
<em>building</em>, <em>uploaded</em>, <em>dep-wait</em>,
<em>BD-Uninstallable</em>, <em>failed</em>, <em>not-for-us</em> и
<em>installed</em>.</p>

<p>Значение этих состояний таково:</p>
    <dl>
      <dt><a name="needs-build">needs-build</a></dt>
      <dd>Пакет, отмеченный как <em>needs-build</em>, имеет
	новую версию, загруженную сопровождающим этого пакета, но для другой
	архитектуры, чем та, базу данных которой вы просматриваете; по сути,
	этот пакет должен быть пересобран. Если пакет имеет состояние
	<em>needs-build</em>, он ещё не был выбран
	утилитой автоматической сборки, но будет выбран ей (как только эта утилита будет доступна,
	а этот пакет будет недалеко от верха списка). Обычно люди
	говорят: <q>пакет поставлен в очередь на пересборку</q>, когда они
	говорят о пакете, имеющем состояние <em>needs-build</em>.<br />
	Интересно будет отметить, что очередь <em>needs-build</em>
	не является FIFO очередью; скорее она упорядочивается
	на основе следующих критериев:
	<ol>
	  <li>Состояния предыдущей компиляции пакетов; пакеты, которые
	    были собраны ранее, получают приоритет над новыми
	    пакетами.
	  </li>
	  <li>Приоритета (пакеты с приоритетом <em>необходимый</em> имеют больший
	    приоритет по сравнению с пакетами, имеющими приоритет <em>дополнительный</em>)
	  </li>
	  <li>Раздела, в котором находится пакет. Этот порядок основан на том, какие
	    пакеты считаются более важными; например, пакеты из раздела <em>games</em>
	    собираются после сборки пакетов из раздела <em>base</em>, а из раздела <em>libs</em>
	    собираются перед <em>devel</em>.
	  </li>
	  <li>В соответствии с порядком букв в ASCII.</li>
	</ol>
	Кроме того, при определённых условиях, может случиться так, что buildd
	не будет брать пакеты из головы очереди; например,
	когда buildd не может найти исходный код данного проекта, он
	поместит его обратно в очередь (куда этот пакет помещается на предыдущую
	позицию, т. е. в голову списка), но этот пакет
	будет игнорироваться в течении нескольких часов. Другим примером того, когда это
	может произойти, является случай, когда какая-то архитектура имеет несколько машин автоматической сборки;
	в этом случае те, кто занимается переносом пакетов на эту архитектуру, могут решить
	собрать большие пакеты на быстрых машинах автоматической сборки и оставить
	небольшие пакеты для более медленных машин. Также утилита buildd теоретически может
	явным образом запрашивать другой порядок разделов,
	но это обычно не делается.<br />
	Могут быть и другие ситуации, когда порядок в очереди, как кажется,
	игнорируется; но заметьте, что все эти случаи являются исключениями.
      </dd>
      <dt><a name="building">building</a></dt>
      <dd>Пакет отмечается как <em>building</em> с того момента,
	когда машина автоматической сборки выбирает его с верха очереди wanna-build, эта
	отметка сохраняется до тех пор, пока администратор машины автоматической сборки не ответит на высланный ему журнал сборки. Поскольку
	пакеты не выбираются один за другим, пакет может быть
	(и обычно является) обозначен как <em>building</em> до того момента, как сборка
	фактически начнётся; тем не менее, поскольку buildd собирает пакеты в
	своей локальной очереди на основе принципа FIFO, этот процесс больше не должен
	занимать долгое время. Кроме того, заметьте, что состояние пакета
	<strong>не</strong> изменяется сразу же после завершения сборки, а лишь
	после того, как администратор машины автоматической сборки сможет ответить на
	сообщение, содержащее журнал сборки.</dd>
      <dt><a name="uploaded">uploaded</a></dt>
      <dd>Если попытка сборки оказалась успешной, журнал сборки высылается
	администратору машины сборки и на buildd.debian.org. Сопровождающий
	машины автоматической сборки должен подписать файл .changes, который
	содержится в журнале сборки, и переслать его на
	машину автоматической сборки. В ответ машина автоматической сборки загрузит
	этот пакет и установит ему состояние <em>uploaded</em>. Как таковой, пакет в
	этом состоянии может быть найден во входящей очереди
	(где-то).<br />
	Машина автоматической сборки больше не будет трогать пакет после того,
	как его состояние станет <em>uploaded</em>, по меньшей мере, до следующей загрузки или
	до тех пор, пока тот, кто занимается переносом этого пакета, вручную не изменит его состояние.
      </dd>
      <dt><a name="dep-wait">dep-wait</a></dt>
      <dd>Если пакет не может быть собран из-за того, что отсутствуют пакеты, необходимые для сборки,
	сопровождающий машины автоматической сборки вышлет письмо на
	машину автоматической сборки, сообщив ей команду удалить исходный код данного пакета и
	отметить его как <em>dep-wait</em> из-за отсутствия
	зависимостей для его сборки. Пакет в этом состоянии будет
	автоматически, без какого-либо вмешательства человека отмечен
	как needs-build, когда эти зависимости будут доступны.<br />
	Изначально должна была быть проведена попытка собрать пакет до того, как
	сопровождающий смог бы вручную поместить его в состояние
	<em>dep-wait</em>. Тем не менее, в августе 2005 года в
	wanna-build был добавлен код, который производит перемещение пакета из состояния <em><a
	href='#installed'>installed</a></em> напрямую в состояние
	<em>dep-wait</em>, если это возможно.<br />
	Существует два особых случая, когда может произойти так, что
	пакет оказывает отмеченным как dep-wait навсегда; в частности, когда
	сделана опечатка при указании зависимостей <em>dep-wait</em>
	(то есть, пакет обозначен как dep-wait от пакета, который
	не существует сейчас и вообще не будет существовать), и когда зависимости, требуемые для сборки,
	объявлены для пакета, который отмечен как <em>not-for-us</em>, либо
	который находится в списке <em>packages-arch-specific</em>.<br />
	В качестве примера последнего случая рассмотрим три пакета: пакет
	<tt>foo</tt>, которые существует только для архитектуры <tt>i386</tt>; пакет
	<tt>bar</tt>, который существует только для архитектуры <tt>m68k</tt> (и который приблизительно
	выполняет ту же функцию); и пакет <tt>baz</tt>, который может быть
	собран либо с <tt>foo</tt>, либо с <tt>bar</tt>. Если сопровождающий
	пакета <tt>baz</tt> забудет добавить <tt>bar</tt> в список
	Build-Depends, и если он или она добавит последний пакет, когда будет обозначено, что
	<tt>baz</tt> зависит (<em>dep-wait</em>) от несуществующего пакета <tt>foo</tt> для
	архитектуры <tt>m68k</tt>, то состояние <em>dep-wait</em> для архитектуры <tt>m68k</tt>
	должно быть вручную поднято теми, кто осуществляет перенос на <tt>m68k</tt>.
      </dd>
      <dt><a name="bd-uninstallable">BD-Uninstallable</a></dt>
      <dd>Во время конференции debconf9, <a
	href='https://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Йоахим
	Брайтнер (Joachim Breitner) высказал идею о том, чтобы</a> использовать edos-debcheck для проверки
	возможности установки зависимостей для сборки тех пакетов, которые в противном случае перешли бы
	в состояние Needs-Build. В тот момент в wanna-build уже
	присутствовала возможность проверки непосредственной доступности
	зависимостей для сборки; но если пакет не может быть установлен потому, что
	его сборка зависит от какого-то пакета a, который зависит от какого-то пакета b, который зависит
	от какого-то пакета c (&gt;=1.2.3), а пакет c доступен только в версии 1.2.2, это
	не было бы определено, а сборка бы почти сразу же завершилась бы с ошибкой из-за
	того, что зависимости для сборки недоступны. Раньше обнаружение этой ситуации было делом
	администратора buildd и выполнялось вручную, как правило это было довольно длительным
	процессом. С заплатой BD-Uninstallable это более не является
	проблемой. Когда ваш пакет находится в состоянии BD-Uninstallable, это означает, что
	одна из его зависимостей для сборки не может быть установлена (непосредственно,
	либо из-за того, что часть её дерева зависимостей
	недоступна). К сожалению, заплата BD-Uninstallable не предоставляет
	информации о том, какой точно пакет отсутствует;
	пожалуйста, чтобы узнать это, используйте edos-debcheck. Тем не менее, эта проблема будет
	решена сама — когда отсутствующие зависимости станут
	доступны, тогда ваш пакет будет снова автоматически
	перемещён в Needs-Build.
      </dd>
      <dt><a name="wanna-build-state-failed">failed</a></dt>
      <dd>Если попытка сборки была неудачной, и сопровождающий машины автоматической
	сборки решил, что это действительно является проблемой, которая не должна быть
	повторена, пакет отмечается как <em>failed</em>. Пакет будет оставаться в этом
	состоянии, пока тот, кто занимается переносом пакета, не решит, что ему следует
	устранить проблему, либо пока не будет доступна новая версия пакета. Тем не менее, когда будет доступна новая
	версия пакета, предыдущая версия которого была отмечена как <em>failed</em>,
	машина автоматической сборки спросит своего администратора о том,
	следует ли повторить сборку; это сделано для того, чтобы
	пакеты, сборка которых очевидно завершится неудачно, не тратили время
	buildd. Хотя до того, как будет предпринята попытка сборки,
	вряд ли может считаться правильным решением, такая опция доступна
	администратору машины автоматической сборки.<br />
	Заметьте, пакет <strong>никогда</strong> не будет отмечен как
	<em>failed</em> без вмешательства человека.
      </dd>
      <dt><a name="not-for-us">not-for-us</a></dt>
      <dd>Определённые пакеты являются специфичными для какой-то архитектуры; например,
	<tt>lilo</tt>, загрузчик для i386, не должен быть
	пересобран для alpha, m68k или s390. Тем не менее, <em>wanna-build</em>
	не проверяет управляющий файл пакета при создании своей
	базы данных, а лишь имя и раздел пакета, предыдущее
	состояние сборки и приоритет. Таким образом, при первой загрузке
	пакета, предназначенного для какой-то конкретной архитектуры, который не должен быть собран
	на других архитектурах, попытка сборки всё равно будет произведена (но она
	завершится неудачно даже до того как будут загружены и/или установлены
	зависимости, необходимые для сборки).<br />
	Поскольку машины автоматической сборки не должны тратить время на попытки сборки
	пакетов, которые не требуются для их архитектур, существует
	необходимость указывать пакеты, которые не нужно даже пытаться
	собирать. Первым решением этой проблемы было
	<em>not-for-us</em>; тем не менее, поскольку его сложно
	сопровождать, состояние <em>not-for-us</em> в настоящее время считается устаревшим;
	сопровождающим машин автоматической сборки следует использовать
	<em>packages-arch-specific</em>, последнее представляет собой скорее
	список пакетов, специфичных для одной или нескольких архитектур, а не
	состояние wanna-build.<br />
	Пакет находящийся в состоянии <em>not-for-us</em>, либо в
	<em>packages-arch-specific</em> <strong>не</strong>
	выйдет из этого состояния автоматически; если ранее ваш пакет явно
	исключал данную архитектуру в своём управляющем файле,
	а теперь включает больше архитектур, он должен быть
	заново помещён в очередь <strong>вручную</strong>.<br />
	Если окажется, что вам следует попросить об этом,
	вы можете попросить соответствующего сопровождающего
	buildd. Вы можете связаться с ними по адресу $arch@buildd.debian.org.
      </dd>
      <dt><a name="installed">installed</a></dt>
      <dd>Как предполагается этим именем, пакет, отмеченный как <em>installed</em>,
	скомпилирован для архитектуры данной базы
	данных wanna-build. До выпуска Woody состояние пакета изменялось с
	<em>uploaded</em> на <em>installed</em> после ежедневного запуска
	katie. Тем не менее, с реализацией <a
	  href="https://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html">Accepted-autobuild</a>,
	это больше не так; теперь пакет переходит
	из состояния <em>uploaded</em> в <em>installed</em>, когда он
	будет принят в архив. Это означает, что пакет обычно
	отмечается как <em>installed</em> через, в среднем,
	15 минут.
      </dd>
    </dl>
    <p>В дополнение к этим трём состояниям, <em>wanna-build</em> также
    известны два состояния -removed, которые являются крайними случаями. Это
    два следующих состояния: <em>dep-wait-removed</em> и
    <em>failed-removed</em>. Они связаны со своими соответствующими <q>обычными</q>
    состояниями следующим образом: когда пакет в состоянии <em>failed</em> или
    <em>dep-wait</em> не встречается в новом файле Packages, который
    передаётся <em>wanna-build</em> &mdash; если кажется, что он был
    удалён &mdash; информация об этом пакете не выбрасывается,
    как это произошло бы, если бы этот пакет, не встречающийся в
    файле Packages, был лишь временной ошибкой, или этот пакет был
    временно удалён по некоторой причине (но снова появится
    в архиве через некоторое время). Вместо этого в таком случае
    пакет переходит в состояние <em>-removed</em>, так что информация
    о том, почему его сборка была неудачной или какие пакеты ожидались данным пакетом, может
    быть сохранена. В случае, если этот пакет снова появится в следующем файле Packages,
    который передаётся wanna-build, он будет перемещён из состояния
    <em>failed-removed</em> обратно в состояние <em>failed</em>, либо из состояния
    <em>dep-wait-removed</em> обратно в состояние <em>dep-wait</em> до его дальнейшей
    обработки.</p>
    <p>
      Невозможно получить прямой доступ к базе данных wanna-build;
      эта база данных установлена на ftp-master.debian.org, который является
      ограниченным узлом, лишь машины автоматической сборки имеют SSH-ключ, который
      позволяет им получать доступ к базе данных wanna-build их
      архитектуры. Так было ещё до того, как ftp-master был
      ограничен; поскольку wanna-build осуществляет блокировку базы данных, когда
      кто-то получает к ней доступ (даже для чтения), вы должны быть членом соответствующей
      группы (wb-&lt;arch&gt;), чтобы иметь возможность получить прямой доступ к
      базе данных wanna-build.
    </p>
    <p>Однако, вы можете увидеть в каком состоянии находится тот или иной пакет,
      обратившись к <a href="https://buildd.debian.org/stats/">странице статистики
        buildd</a>, исключением являются пакеты, находящиеся в состоянии <em>installed</em>
	(ну, если вы, конечно, не хотите копаться в
	многомегабайтных файлах "&lt;arch&gt;-all.txt"...).
    </p>
    <h2>Журналы результатов сборки</h2>
    <p>
      Когда пакет собирается при помощи sbuild (компонент buildd, который
      осуществляет фактическую сборку), по почте администратору машины автоматической
      сборки, а также на logs@buildd.debian.org высылается журнал с результатом сборки
      (последнее нужно для того, чтобы журнал попал на https://buildd.debian.org). Результат журнала
      сборки может быть <em>successful</em>, <em>attempted</em> (ранее этот результат
      был известен как <em>failed</em>),
      <em>given-back</em> или <em>skipped</em>. Заметьте, что на <a
      href="https://buildd.debian.org/">обзорной странице журнала
      buildd</a>, добавляется префикс <em>maybe-</em>, поскольку, помимо
      прочего, тот факт, что сборка может быть отмечена как
      <em>failed</em>, существование таких состояний, которые <em>в действительности</em> не
      являются неудачными, в прошлом вызывали путаницу (либо, наоборот,
      иногда пакет, который, по-видимому, был успешно собран, в действительности оказывается сломанным
      и требует своей пересборки).</p>
    <p>Значение
      результатов журнала определяется следующим образом:</p>
    <dl>
      <dt><a name="successful">successful</a></dt>
      <dd>Сборка была успешной. Когда сопровождающий машины автоматической сборки
	получает этот журнал, он вынимает прикреплённый
	файл <code>.changes</code>, подписывает его и отправляет обратно на
	машину автоматической сборки, что приводит к загрузке пакета.</dd>
      <dt><a name="failed">attempted</a> (ранее: failed)</dt>
      <dd>Сборка завершилась с ненулевым кодом ответа, что означает, что сборка вероятнее всего
	была неудачной. Поскольку существует много причин, почему сборка может быть неудачной,
	перечисление всех возможных причин было бы утомительно, поэтому здесь мы их не приводим. Если
	ваш пакет отмечен как <em>(maybe-)failed</em>, вам следует
	прочитать первую часть настоящего документа и проверить текущее состояние wanna-build для вашего пакета.
      </dd>
      <dt><a name="given-back">given-back</a></dt>
      <dd>Сборка была неудачна из-за временной проблемы с машиной
	автоматической сборки; например, это могут быть проблемы с сетью,
	недоступность источников пакетов с текущим файлом
	sources.list, недостаточное количество места на диске и др.<br />
	Пакет, имеющий состояние <em>given-back</em> отмечается
	как <em><a href="#needs-build">needs-build</a></em> снова; как
	таковой, он будет автоматически выбран другой машиной автоматической сборки,
	как только она будет готова.
      </dd>
      <dt><a name="skipped">skipped</a></dt>
      <dd>Между тем моментом, когда пакет был выбран машиной
	автоматической сборки и отмечен как <em><a
	    href="#building">building</a></em>, и моментом самой попытки сборки, была
	    загружена новая версия этого пакета, либо тот, кто осуществляет перенос, вручную
	    изменил состояние wanna-build по какой-то другой причине. Когда такое происходит,
	    на машину автоматической сборки высылается сообщение, которое отмечает
	    этот пакет как пакет, который не нужно собирать; sbuild видит это и пропускает
	    сборку (хотя и высылается журнал сборки с результатом, описывающим
	    произошедший факт).
      </dd>
    </dl>

<h2><a name="graphlink">Графическая версия</a></h2>
<p>Для иллюстрации приведённой выше информации, мы подготовили <a
href="wanna-build.png">блок-схему</a> процедуры сборки. Опять же, заметьте, что
эта схема не содержит всего того, что указано в настоящем документе.
</p>