Re: [devel] [JT] Re: RFC: тестирование входящих пакетов полной пересборкой сизифа

[Alexey Tourbin <at@altlinux.ru>]

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

On Thu, Aug 23, 2007 at 04:12:53PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 04:19:40PM +0400, Alexey Tourbin wrote:
> > То что ты предлагаешь я делал 2 года назад.  Для каждого
> > src.rpm пакета хранится список пакетов билдрута от предыдущей
> > его сборки.  То есть таблица <pkg-name> <rpm-file-basename>.
> > (На самом деле достаточно хранить только rpm-file-basename,
> > потому что отрезанием -version-release-*.rpm получается
> > pkg-name).  Теперь достаточно "гнепнуть" (join'ом) старые
> > списки на предмет совпадения pkg-name относительно прибывших
> > пакетов.  Это не только не решает Provides+Obsolets, это не
> > решает даже виртуальных зависимостей.
> 
> Хорошо, а инвалидировать такой кэш на основании сравнения
> выдранных из пакета BR?

Список BR оптимизируется, в этом есть свой смысл.
То есть то, реализовано в /usr/share/buildreqs/optimize_package_list
является не просто оптимизацией, но и "кристализующей" оптимизацией,
проясняющей "смысл понятия".  Например, библиотека lib1 может быть
собрана сначала с backend1, а позднее пересобрана с backend1.
Отсутствие backend1|backend2 в BR при наличии lib1 является БЛАГОМ.

К сожалению, в каких-то эзотерических терминах объяснение получается. :)

> > Например пришёл пакет libstdc++4.2-devel.  Его в предыдущих
> > списках нигде нет.  Значит, наша система "не догадается"
> > пересобрать приплюснутые пакеты.  Такое простое опровержение
> 
> Согласен; хотя на такие варианты можно попробовать тоже найти
> эвристику подешевле, чем --print-uris -- например,
> ^([a-zA-Z_+-]+)[0-9]+(\.[0-9]+)-devel или около того сводится 
> к более общей сущности \1-devel, которая и проверяется на наличие 
> в BR (или по /etc/buildreqs/packages/substitute.d/ -- хотя для
> новой сборки записи ещё нет).
> 
> Я к тому, что если решение задачи "в лоб" оказывается слишком
> дорогим, может иметь смысл разбавить решаемую задачу до 
> "в большинстве практических случаев".

Это не только тестирование для практических случаев.  У меня есть идея,
боюсь что я сейчас не смогу ее четко сформулировать без привлечения
эзотерики.  Смысл идеи в том, что каждый входящий пакет переводит
репозиторий из состояния1 в состояние2.  Переход является
транзакционным, то есть в момент перехода разница между состоянием1
и состоянием2 должна быть четко определена (а сам переход "фиксирует"
эту разницу).  Состояние, в частности, включает в себя статус
пересборки всех пакетов.  То, что мы сейчас обсуждаем, это "как
подешевле выяснить состояние2 в той его части, которая касается
пересобираемости пакетов".  То есть это мини-проблема при bottom-up
подходе.  Но решение ее должно быть надежным, иначе неопределенность
будет наслаиваться, и уже ничего нельзя будет утверждать наверняка.
Так, при переходе состояниеN->состояние(N+1) может выясниться, что
очередной пакет очень много всего сломал, тогда как поломка могла
случиться намного раньше, просто наши регулярные выражения дали сбой.

Другая часть фиксации состояния -- это, например, изменение количества
анметов.

В общем, после того, как пакет собрался в хешере, нужно для него
вычислить новое состояние, на основе целого ряда проверок, как минимум
пересборка и анметы.  Если новое состояние не хуже старого, тогда
фиксация проходит автоматически.  Если же оно является в чем-то хуже
старого, тогда требуется подтверждение или retract вручную, со стороны
maintainer'а пакета и/или со стороны "ответственного товарища".

То что "слишком дорого" это в конечно счете надо смотреть во сколько
это выльется по деньгам.  Прибедняться тоже не надо, кашу из топора
не сваришь, значит нужно обстоятельно прикинуть, чево и сколько хотелось
бы иметь.  И что это дает.  Я считаю что предварительное вычисление
состояния2 дает очень много -- по сути это разница между знанием и
невежеством, между высокой определенностью и высокой неопределенностью.

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