[devel] [#58022] FAILED (try 2) srpm=libgupnp-igd-0.2.0-alt1.src.rpm srpm=libnice-0.1.1-alt1.src.rpm ...

[Mikhail Efremov]

On Fri, 18 Nov 2011 12:38:48 +0400 Yuri N. Sedunov wrote:
> В Чтв, 10/11/2011 в 00:27 +0400, Dmitry V. Levin пишет:
> > On Wed, Nov 09, 2011 at 02:16:58PM +0400, Yuri N. Sedunov wrote:
> > > Ну, если уж "python2.6 dependencies are no longer allowed" недостаточно,
> > > чтобы сборка питоньего задания не зависела от обновляющегося сизифа,
> > > лучше отдать ему сборочницу на недельку, -- небось пасьянс быстрее
> > > сойдется.
> > 
> > Сейчас, пока не все пакеты собрались, это вроде бы не обязательно.
> > Потом, когда task#56981 дойдет до стадии проверок, я планирую включить
> > режим защиты сборочной среды task#56981 от изменений со стороны других
> > заданий.
> 
> Почему б было не сбросить все независимые друг от друга пакеты в хвост
> питоньего задания, не тянуть эту последовательно-бессмысленную канитель,
> а  пересобрать этот хвост быстро-быстро?

Лучше бы иметь возможность ставить задания в очередь ожидания сборки
другого задания. Т.е. возможность сказать task run --queue 56981,
переводящее задание в какое-то новое состояние QUEUE, не мешающее
собирать другие пакеты тем же мантейнером. После того, как task 56981
перейдет в состояние DONE можно было бы пройтись по очереди и перевести
все эти задания в состояние AWAITING, запуская их сборку по обычным
правилам.
Просто в случае "долгих" заданий, вроде 56981, действительно легко
забыть о том, что хотел там что-то собрать. И если даже помнить, то к
тому времени задание скорее всего уже заархивируется и придется
создавать новое (дергать же его периодически нет никакого смысла, да и
напряжно).
Кстати, тогда можно было бы задания, мешающие 56981, не отфутболивать, а
ставить автоматом в эту очередь.

-- 
WBR, Mikhail Efremov