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

[Igor Vlasenko]

On Sun, Aug 26, 2007 at 02:43:50AM +0400, Alexey Tourbin wrote:
> On Sun, Aug 26, 2007 at 12:58:34AM +0300, Igor Vlasenko wrote:
> > У меня на 400 пакетов 25 git репозиториев,
> > Мясо на кости долго нарастает...
> > Если же найдутся люди с установкой
> > "Железной рукой загоним человечество к счастью",
> > боюсь, и та что есть скотина передохнет...
> 
> Во-первых, не страдайте раньше времени.
Да я и в`о время страдать не хочу.
И призываю не заставлять других страдать.
 
> Во-вторых, хочу спросить: как желание собирать пакеты пачкой связано
> с последующей возможностью частичного ("точечного") обновления?

Здесь более общая проблема теории баз данных,
а именно транзакции против глобальных блокировок.

Если пакеты связаны цепочкой зависимостей, получается ступор.
Пример из жизни. 
Есть 2 цепочки зависящих друг от друга пакетов.
пакеты 1й цепочки 15 шт. -- новые версии, порождают unmets и зависят друг от друга.
пакеты 2й цепочки 15 шт. -- закрывают свои unmets, 
с патчами на новые API или исправленными Requires.

пакеты 2й цепочки здесь просто для красоты, чтобы не ломать сизиф.
Они после пакетов 1й цепочки пройдут легко.

Основная проблема в 1й цепочке -- 
пусть на каждый 3-й пакет из 1й цепочки робот будет накладывать
блокировку и ее надо будет снимать вручную.

Итого пять раз придется вручную и в разные дни снимать блокировку, 
поскольку времени не хватает и возможность не всегда есть,
то это 5-7 дней бессмысленного простоя и бессмысленной работы :(

> Влияет ли собираемость пакетов "пачкой" на их последующую
> работоспособность пачкой/не пачкой?  Отражено ли это влияние в
> зависимостях собранных пакетов?

да. они связаны цепочкой зависимостей.

> это всё дело довольно подозрительное.

Это примеры не выдуманные, а скорее наболевшие и 
уже в печенках сидящие.
Например у меня что-то подобное происходит 
каждый раз, когда я меняю пакет java c altquirks на 
стандартный совместимый.

И без этих проверок incoming не успевает обрабатывать,
а тут вообще будет.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine