Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey Tourbin <at@altlinux.ru>]

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

On Wed, Feb 18, 2009 at 10:09:13PM +0200, Igor Vlasenko wrote:
> On Wed, Feb 18, 2009 at 04:20:14PM +0300, Alexey Tourbin wrote:
> > Придётся в рамках одного задания чинить все пакеты.
> 
> Это подходит для простого паттерна:
> обновилась библиотека - починили клиенты.
> 
> Для сложных случаев с многоступенчатым бутстрап-процессом
> это не пойдет.

Вы хотите оставить репозитарий в разломанном состоянии "на честном
слове", что со временем пойдут какие-то многоступенчатые процессы,
и низшая углеродная фракция реактивного двигателя со временем отпадёт,
как глазьевская партия "Родина", как несмысленные галаты, которые отпали
от благодати.

Но в этом же самое время репозитарием пользуются другие люди (а также
на нём собираются пакеты).

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

> > С src.rpm пакетами это будет сделать несколько сложнее,
> > чем с gear-репозитариями.
> 
> С src.rpm пакетами сделать одной транзакцией не возможно,
> конечно.

Вроде бы, можно.  Насколько я знаю, все src.rpm пакеты (одного
мейнтейнера), залитые в incoming за время дельта-тэ, формируют
отдельное задание.  Правда, если задание не проходит, то весь
набор пакетов придётся заливать заново.

> Вопрос не в этом. С этими unmets что здесь чему служит?
> Суббота для человека или человек для субботы?
> 
> Технически робота обмануть очень легко. Для этого достаточно
> подмешать в транзакцию пакет пустышку, который провайдит все 
> анметы и еще золотые горы в придачу, и следующей транзакцией
> удалить пустышку.

Робота будет обмануть сложнее, когда тестовая пересборка пакетов
станет обязательным условием.

> Когда я выкладывал maven 2.0.7, как раз был переезд, 
> пакет первый раз не прошел. Я посовещался с Димой и
> мы пришли к выводу, что проще добавить provides в пустышку.
> 
> Сам по себе unmet ни плох, ни хорош. Все зависит от контекста 
> его появления. Как человек с пистолетом может нарушать порядок,
> а может и поддерживать его. А пистолет сам по себе ни хорош ни плох.

И да, и нет.  Как правило, антметы нарушают целостность репозитария,
не предоставляя взамен никаких выгод.  В редких случаях проще создать
анмет, чтобы потом достаточно быстро его ликвидировать.  Но это
открывает промежуток времени дельта-тэ с достаточно непредсказуемыми
последствиями для репозитария.  Новый "временный" анмет может
заблокировать сборку других пакетов.  Просчитать последствия отдельно
взятого анмета -- это нетривиальная задача.  В худшем случае после
появления анмета перестанет работать 'hsh --initroot', и без грубого
вмешательства уже никак нельзя будет вывести систему из ступора.

Я вообще изначально хотел сделать общий список "нефатальных нарушений"
задания, и относить анметы к этому списку, чтобы можно было их
контролировано допускать (аналог "посовещаться с Димой").  Но, в общем,
пока проверка на анметы работает безусловно.

> А я не робот, чтобы уместить многоступенчатое обновление на 
> 50-150 пакетов в одну транзакцию. 
> А раз в год-полгода у меня такая необходимость возникает :(

Делать большие переезды одной транзакцией, конечно, неудобно,
но возможно, кроме некоторых случаев bootstrap.

А может быть, если требуются такие "полные переезды", то это значит,
что задана слишком жесткая система связей между пакетами?  Для noarch
пакетов жесткую систему связей обычно можно немного ослабить.

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