ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Alexey Tourbin <at@altlinux.ru>
To: devel@lists.altlinux.org
Subject: [devel] RFC: тестирование входящих пакетов полной пересборкой сизифа
Date: Wed, 22 Aug 2007 01:43:21 +0400
Message-ID: <20070821214321.GB28786@solemn.turbinal> (raw)

[-- Attachment #1: Type: text/plain, Size: 4751 bytes --]

Я заметил, что branch 4.0 перед выкладыванием проходит тестирование
пересборкой.  Всё это делается вручную.  У меня есть предложение
внедрить аналогичную схему _автоматической_ пересборки для сизифа.

Я систематизирую идеи, которые обсуждал на конференции с ldv.
К сожалению, мне не удалось обсудить это с legion'ом.

Предыдущее обсуждение этой же темы здесь:
http://lists.altlinux.org/pipermail/devel/2007-April/045149.html
http://lists.altlinux.org/pipermail/devel/2007-April/045288.html
(и вообще все письма в этом треде -- "git.alt build")

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

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

Поясню некоторые выражения в кавычках.

"Полную пересборку сизифа" следует трактовать не буквально, а вот как:
пересобрать все пакеты, у которых при сборке в билдрут ставится один из
новых пакетов.  Это означает, что, с учетом поступивших пакетов, для
каждого src.rpm пакета формируется список пакетов для билдрута.  Если в
списке пакетов для билдрута оказывается новый пакет, то этот src.rpm
пакет подлежит пересборке.

"Успешная пересборка" сизифа подразумевает сравнение с предыдущим
статусом "полной пересборки сизифа".  Если по сравнению с предыдущей
полной пересборкой какой-либо пакет перестал собираться, значит,
пересборка не является успешной.

"Подтверждение" означает осознанное действие со стороны maintainer'а
пакета и/или "формирующего очередной релиз сизифа" по отношению к
пакету, который что-то сломал.  То есть можно вручную подтвердить,
что новый пакет всё же не настолько плох, чтобы не пускать его в сизиф
(например, виноваты другие пакеты, или же ожидается их скорое
исправление).

Вижу две проблемы: теоретическую (сериализация) и ресурсы.

Сериализация.  В идеале таким образом пакеты должны идти в очередь один
за другим, и очередь не должна двигаться, пока не будет принято решение
по каждому очередному "неидеальному" пакету.  К сожалению, полная
сериализация будет упираться в человеческий фактор (подтверждение
вручную) и поэтому нетехнологична.  То есть проблема в том, что
параллельно протестированные пакеты могут по отдельности ничего не
ломать, а комбинация двух новых пакетов может дать уже другой исход.
Пример.  Прошел пакет libxml2 и успешно протестировался пересборкой
старой версии perl-XML-LibXML.  Параллельно прошел новый пакет
perl-XML-LibXML и успешно протестировался на старой версии libxml2.
Но, может статься, новый perl-XML-LibXML уже не будет собираться
на новой версии libxml2.

На самом деле такого рода "конкурентные изменения" рассматриваются
в теории RDBMS.  Там есть разные уровни изоляции транзакций и т.д.
Может кто знает.

Ресурсы.  На самом деле для "среднего пакета" потребуется не слишком
много сборочных ресурсов.  Недавно я выяснил (и написал), что число
пакетов в сизифе, у которых в билдруте при сборке есть библиотека
libcurl, это число равно 69 (если не ошибаюсь).

Конечно, если пакет ставится в базовую сборочную среду, тогда
возможность уменьшения списка пакетов исчезает.  Но, может быть,
кто-нибудь помнит историю с битым cpio ("cpio обновился, и hasher
сломался").  Так что ресурсы на полную пересборку сизифа при прохождении
базовых пакетов не стоит считать потраченными напрасно.

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

Техническая проблема на подступах к определению списка пакетов, подлежащих
пересборке, было в том, что нужно научиться очень быстро строить список
пакетов в билдруте при сборке каждого src.rpm пакета.  Стандартный
способ (который используется в hasher, через --print-uris) занимает
порядка одной секунды на src.rpm пакет.  Это связано с тем, что apt всё
время перечитывает свой кеш.  В сизифе около 6000 src.rpm пакетов, значит,
определять, какие из них нужно пересобрать, можно около 2 часов.  Это
даже больше, чем может занять последующая пересборка обнаруженным таким
образом src.rpm пакетов.  У меня сейчас зреет решение, как немного
захачить апт и написать к нему скрипт на lua, чтобы построение списка
пакетов для пересборки по времени сводилось к чтению хедеров src.rpm
пакетов.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2007-08-21 21:43 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-21 21:43 Alexey Tourbin [this message]
2007-08-22  5:25 ` Денис Смирнов
2007-08-22  8:22   ` Хихин Руслан
2007-08-23 10:19 ` Alexey Tourbin
2007-08-23 11:10   ` Michael Shigorin
2007-08-23 11:16     ` Mykola S. Grechukh
2007-08-23 11:18       ` Mykola S. Grechukh
2007-08-23 11:52         ` [devel] [JT] " Michael Shigorin
2007-08-23 12:10           ` Mykola S. Grechukh
2007-08-23 12:11             ` Michael Shigorin
2007-08-23 12:32               ` Alexey Tourbin
2007-08-23 19:05                 ` [devel] статистика Alexey Tourbin
2007-08-23 20:25                   ` Alexey Tourbin
2007-08-23 20:37                   ` Vadim V. Zhytnikov
2007-08-23 19:51                     ` Alexey Tourbin
2007-08-23 21:03                     ` Alexey Tourbin
2007-08-23 21:08                   ` Хихин Руслан
2007-08-23 21:47                     ` Alexey Tourbin
2007-08-23 21:59                       ` Alexey Tourbin
2007-08-23 22:19                       ` Alexey Tourbin
2007-08-23 12:19           ` [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа Alexey Tourbin
2007-08-23 13:12             ` Michael Shigorin
2007-08-24 11:15               ` Alexey Tourbin
2007-08-25  9:15                 ` Alexey I. Froloff
2007-08-25  9:33                   ` Alexey Tourbin
2007-08-25 10:16                     ` Alexey I. Froloff
2007-08-25 11:25                       ` Igor Vlasenko
2007-08-25 11:36                         ` Igor Vlasenko
2007-08-25 11:48                           ` Michael Shigorin
2007-08-25 11:53                             ` Mykola S. Grechukh
2007-08-25 21:58                               ` Igor Vlasenko
2007-08-25 22:43                                 ` Alexey Tourbin
2007-08-25 23:35                                   ` Igor Vlasenko
2007-08-26 13:38                                   ` Alexey I. Froloff
2007-08-25 18:33                       ` Alexey Tourbin
2007-08-25 19:32                         ` [devel] incominger Michael Shigorin
2007-08-25 20:13                         ` [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа Денис Смирнов
2007-08-23 13:23   ` [devel] " Alexey Tourbin
2007-08-24 12:51     ` Alexey Tourbin
2007-08-24 21:23     ` [devel] статистика [2] Alexey Tourbin
2007-08-25 14:57       ` [devel] Критерий значимости пакета (Was: статистика) Alexey Rusakov
2007-08-25 20:10         ` Денис Смирнов
2007-08-25 20:28           ` Alexey Tourbin
2007-08-25 22:47             ` Денис Смирнов
2007-08-25 23:55               ` Alexey Tourbin
2007-08-29 20:39       ` [devel] статистика [2] Dmitry V. Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070821214321.GB28786@solemn.turbinal \
    --to=at@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git