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 пакетов жесткую систему связей обычно можно немного ослабить.