On Fri, May 22, 2009 at 07:07:36PM +0300, Igor Vlasenko wrote:
> On Fri, May 22, 2009 at 07:02:33PM +0400, Alexey Tourbin wrote:
> > > Эту же цель можно достичь гораздо дешевлее,
> > > реализовав рабочие карманы для всех желающих.
> > > из этих желающих вырастет новое поколение 
> > > и тестеров, и мейнтейнеров.
> > 
> > Ага, то есть содержимое карманов не предназначено для помещения
> > в репозитарий.  
> 
> да, в том смысле, что оно сразу в репозиторий не попадает,
> но есть возможность при наличии 
> (прав|разрешения RM|разрешения майнтайнера), перезалить
> содержимое кармана на сборку в бранч/сизиф.

Если первоначально не закладывать интеграцию с girar-builder и
возможность взять пакеты в репозитарий (с пересборкой, если она
потребуется), тогда идея карманов получается ещё более неопределенной.
В интернете места много, а hasher как индивидуальный инструмент есть
каждого.  И перезалить пакеты на сборку в git.alt тоже никто не
запрещает.  Это просто будет какая-то другая инфраструктура, которая
меня не интересует.

А если сразу закладывать интеграцию с girar-builder, тогда опять не
понятно, о чем разговор.  Просто заливайте пакеты на сборку.  Если
ошибок не обнаружено, то они автоматически проходят.  Проверка ACL
должна выполняться последней, так что если не хватает прав, то можно
просить NMU у мейнтейнера и/или администратора/RM.  Именно на эту
сборку!  Смысл NMU как раз в том, что его надо давать на конкретную
сборку, а не на неизвестно что.

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

> > Когда мы начинаем
> > собирать карман, надо делать lock репозитария на чтение, чтобы во
> > время установки пакетов не оказалось, что репозитарий уже изменился.
> 
> лок на чтение можно, например, заменить хардлинк-копией репозитория.

У меня нет административного доступа к серверам, и я даже слабо
представляю себе, каким образом копии репозитария распределены между
серверами.  Хардлинк-копии в принципе возможны, и это один из вариантов.
Сейчас используются симлинк-копии репозитария.

Но даже чтобы сделать хардлинк-копию репозитария, надо брать lock
на чтение.  Репозитарий постоянно обновляется, а сборка задания берёт
лок на запись.  И это правильно, потому что во время сборки задания
репозитарий нельзя обновлять.  Но, получается, что во время сборки
задания репозитарий нельзя и читать.  Значит, нужна другая семантика
блокировки (multiple-reader/single-writer), с промежуночной ступенью
IWRITE (shared with READ, but conflicts with WRITE and IWRITE).
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/cam_conv.html
Конечно, всё это чисто технические трудности.

> Более того, 
> поскольку это карман, то от технически сложных или ресурсоемких
> проверок можно и отказаться, частично.
> А проводить их только для пакетов, помещаемых в репозитарий.

Сейчас выполняются только проверки, которые отлавливают грубые ошибки:
проверка зависимостей, контроль ABI и установка пакетов.  Эти проверки
занимают относительно немного времени (время сборки варьируется гораздо
сильнее).  Пока тут не на чем экономить.

> > И надо ли брать такой лок per package или per карман, это всё непростые
> > вопросы.
> В случае проблем для карманов можно пожертвовать строгостью.