[devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Чт Авг 23 16:19:40 MSD 2007
On Thu, Aug 23, 2007 at 02:52:25PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 02:18:40PM +0300, Mykola S. Grechukh wrote:
> > простейший пример - если пакетов qnetwalk поставить
> > Provides: kdelibs
> > Obsoletes: kdelibs
> >
> > .. то старые списки покажут, что его никто не использует.
> > А на самом деле разломается сборка всего кдешного.
>
> Я же написал -- "80%". Инженер по качеству и полицейский с
> дубинкой -- немного разные роли, даже если и пересекающиеся.
>
> С такими аргументами... от rm -rf в %post тоже никаких страховок
> нет, и по существу быть не может.
Это другая проблема. Я сделал постановку задачи для своей пробемы.
Она примерно такая. В сизиф собрался новый бинарный пакет (или
несколько пакетов из одного src.rpm пакета). Теперь для каждого
src.rpm пакета нужно КАК БЫ инициализировать сборочный билдрут
и посмотреть, не встал ли в какой из этих билдрутов один из вновь
пришедших пакетов. Если в билдрут для сборки src.rpm пакета встаёт
один из пришедших пакетов, то этот src.rpm пакет нужно тестировать
пересборкой.
(Соответственно, я играю в "игру" в рамках этой постновки задачи.
В других задачах будут другие подходы. Они тоже есть. legion
когда-то пытался сделать установку+удаление пакета и последующую
проверку чрута через osec. Это надо будет со временем возродить,
или хотя бы понять, что там не склеилось.)
Всё дело, конечно, в том, что означает "КАК БЫ". Реально
инициализировать билдрут для каждого src.rpm пакета это никаких
ресурсов не хватит. Просто делать apt-get --print-uris, не доходя
до установки пакетов в билдрут, это порядка одной секунды на src.rpm
пакет. Я сейчас утверждаю, что есть способ получить аутентичный
результат в 5 раз быстрее.
То что ты предлагаешь я делал 2 года назад. Для каждого src.rpm пакета
хранится список пакетов билдрута от предыдущей его сборки. То есть
таблица <pkg-name> <rpm-file-basename>. (На самом деле достаточно
хранить только rpm-file-basename, потому что отрезанием
-version-release-*.rpm получается pkg-name). Теперь достаточно
"гнепнуть" (join'ом) старые списки на предмет совпадения pkg-name
относительно прибывших пакетов.
Это не только не решает Provides+Obsolets, это не решает даже
виртуальных зависимостей. Например пришёл пакет libstdc++4.2-devel.
Его в предыдущих списках нигде нет. Значит, наша система "не
догадается" пересобрать приплюснутые пакеты. Такое простое
опровержение <...>
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20070823/f8b7ea9e/attachment-0001.bin>
Подробная информация о списке рассылки Devel