[devel] про автоматическое и ручное тестирование пакетов

[Alexey Tourbin]

On Tue, Jun 16, 2009 at 04:03:24AM +0400, Alexey I. Froloff wrote:
> On Tue, Jun 16, 2009 at 03:00:40AM +0400, Dmitry V. Levin wrote:
> > Если никто не будет приводить новые аргументы, то я своё мнение менять
> > не стану.  Это общее правило ведения обсуждения.
> Мне было бы удобно, если бы build/*/*/rpms/*.rpm были бы
> проиндексированы для apt'а:
> 
> rpm http://git.altlinux.org/tasks/НОМЕР/build/repo $(ARCH) task

С этим есть несколько маленьких, но неприятных проблем.

Во-первых, в $(ARCH)-repo лежат разные noarch пакеты.  Строго говоря,
пока не выполнена проверка идентичности noarch пакетов, такие noarch
пакеты нежелательно выпускать во внешний мир.  А когда идентичность
noarch пакетов установлена, только тогда можно выбрать один noarch
пакет и сформировать noarch-repo одинаковый для всех архитектур.
Сейчас для этого выбирается i586-noarch пакет, по косвенному признаку
(потому что i586 лексикографически наименьшая архитектура).

Во-вторых, подписи пакетов.  Пакеты подписываются довольно серьезным
ключом.  Если пакеты не проходят, то этим ключом их нежелательно
подписывать.  Это спорный вопрос.  Я когда над ним думал, то поступил
острожно -- сделал подпись пакетов в gb-task-commit-repo (прямо перед
копированием их в master репозиторий).  Это выглядело несколько нелепо,
и ldv перенес подпись пакетов в gb-task-build-arch-i (сразу после
сборки).

В третьих, stacked мини-репозитории (оверлеи) могут иметь проблемы с
файловыми зависимостями.

RPMS.hasher
 |
 v
RPMS.classic

В этой схеме RPMS.classic генерируется независимо, и в нём удаляется
информация обо всех файлах, которые не нужны (не разрешают внутренние
зависимости).  Нельзя предсказать, какие файлы могут потребоваться в
стек-оверлеях.  Можно только вообще не удалять информацию о файлах в
RPMS.classic.  Но тогда при каждом 'apt-get update' придётся скачивать
индексы примерно вдвое большего размера.

В самом общем виде эту проблему решить нельзя, потому что иначе бы
появилась возможность предсказывать будущее.

> Кривоскрипт в аттаче делает что-то в этом роде (вызывается в
> конце gb-task-build-arch).

В принципе hasher repo автоматически генерируется на remote node,
и поэтому специально делать ничего не надо -- можно просто грамотно
его оттуда скопировать.

> for i in $(src_nums); do
> 	[ -d "build/$i/$arch/rpms" ] || continue
> 	find "build/$i/$arch/rpms" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/RPMS.task" '{}' '+'
> 
> 	[ -d "build/$i/$arch/srpm" ] || continue
> 	find "build/$i/$arch/srpm" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/SRPMS.task" '{}' '+'
> done
> genbasedir \
> 	--topdir=build/repo \
> 	--flat --no-oldhashfile --bz2only --mapi "$arch" task
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090617/1193e710/attachment.bin>