[devel] unmets policy

[Alexey Tourbin]

On Tue, Sep 15, 2009 at 11:52:41PM +0400, Dmitry V. Levin wrote:
> On Tue, Sep 15, 2009 at 11:17:28PM +0400, Alexey Tourbin wrote:
> > On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> > > On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> > > > К сожалению, пока (до появления надлежащей реализации карманов?) 
> > > > некоторые транзакции и workflows сборочницей не поддерживаются.
> > > > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > > > одного и того же пакета (bootstrap-сборка).
> > > 
> > > Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> > > анметы.
> > 
> > Я не знаю как поддержать такие транзакции.  Точнее знаю.
> > Пусть пакеты в задании пронумерованы 1..n.  Предикат
> > пересечения x(i,j), i=1..n, j=1..n, i<j, означает что
> > в пределах задания пакет с большим номером j пересекается
> > с пакетом с меньшим номером i (по имени исходного пакета и/или
> > по имени одного из бинарных пакетов).  Тогда по смыслу пакет i
> > нужно выбросить из плана задания, потому что он был нужен
> > для бутстрапа пакета j.  Пакет j в свою очередь может быть
> > вытеснен пакетом с ещё большим номером.
> > 
> > Пересечение проверяется для всех пар (i,j).  Доказать что
> > окончательный план транзакции не зависит от порядка, в котором
> > проверяются пары (i,j).
> 
> Лучше сразу после сборки подзадания j выкинуть результат сборки всех
> подзаданий i<j, которые пересекаются с результатом сборки подзадания j.
> Я думаю, что мейнтейнеру будет проще предсказать поведение сборочной
> системы, если она будет следовать этому правилу.

Если следовать этой логике, то сейчас после сборки каждого пакета нужно
проводить полное промежуточное замещение в основном репозитории.  Это не
только дорого, но и встаёт вопрос, какие требования предъявляются к
промежуточному репозиторию.  Например собранные пакеты могут
перетасовываться между исходными пакетами; если проводить строгие
замещения, то можно быстро налететь на проблемы.

Поэтому сейчас сборка идёт на repo + RPMS.hasher overlay, а план A0->A1
вычисляется только в самом конце.  Я когда-то решил что ничего лучше
придумать нельзя.  С наскоку по крайней мере.

А как сюда вписать дупы в пределах самого задания?  Сейчас работает
логика "в промежуточное состояние мы в принципе не вклиниваемся",
а дупы просто запрещены.  Поменять её на логику "в промежуточное
состояние мы в принципе вклиниваемся" это очень круто.

> > В общем мне это не нравится, я бо так не стал делать.  Сейчас все
> > транзакции прозрачны: результат сборки каждого пакета зависит от пакетов
> > в репозитарии и дополнительно от пакетов с меньшими номерами, которые
> > однако жо гарантированно попадают в репозиторий.  Прозрачность как бы
> > означает, что имея начальный репозитарий A0 и конечный репозитарий A1,
> > мы имеем все данные, чтобы заново проиграть транзакцию на репозитории
> > A0 и получить в результате идентичный репозитарий A1.  А с бутстрапом
> > такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как
> > на основе A0 воспроизвести A1 повтрно.
> 
> Нет, сейчас знания о A0 и A1 недостаточно для того, чтобы на основе A0
> воспроизвести A1 повторно.  Для этого нужна дополнительная информация,
> которая находится в задании A0->A1.

Почему же недостаточно?  Достаточно, с точностью до некоторых
второстепенных атрибутов типа %packager.  То есть мы смотрим какие
новые пакеты есть в A1 и просто начинаем их собирать.  По окончанию
сборки удаляем старые пакеты и получается репозиторий идентичный A1.
Порядок сборки играет роль, но его можно узнать из buildtime/mtime.
Если бы даже порядок сборки был неизвествен, то его можно обнаружить
перебором.  То есть в принципе, плюс-минус тонкости, мы можем начать
собирать на A0 и получить A1.

А новую модель с бутстрапом в общем виде можно описать так.
Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
только с учетом выбранных m пакетов.  Тогда ясно что если переход A0->A1
выполнен только с учетом m пакетов, то часть информации потерялась.
То есть начать собирать эти пакеты заново и получить A1 уже нельзя
даже в принципе.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090916/241105db/attachment-0001.bin>