On Tue, Aug 16, 2005 at 03:59:17AM +0400, Alexey Gladkov wrote:
> Сейчас сбои случаются из-за того, что incominger не учитывает версии в
>  BuildRequires.

Хешер, кажется, тоже не учитывает версии *виртуальных* пакетов в
BuildRequires.  Их просто apt не понимает.

> Сейчас работаю над реализацией этой проверки. В incominger уже давно
> есть скрипт для проверки unmets, но он не использовался из-за того,
> что genbasedir ооооочень медленно работает.

А в sources.list есть метод rpm-dir, он не поможет?  То есть можно
генерировать не полный репозитарий, а оверлейный как надстройку для
данной транзакции.  В общем, я пока до конца не врубаюсь.  Надо ещё
incominger-0.0.7.3 почитать.

> Все unmets можно классифицировать. После этого можно рассмотреть
> каждую группу и принять решение. Это реально сделать.
> Вопрос в другом и ты его задал. Сделаю это еще раз: что делать если
> неудовлетворенность порождается пакетом от которого зависят другие
> пакеты в разобранном инкоминге?
> По логике нужно исключить битый пакет и попробовать собрать пакеты без
> него. Но это может долгая и бессмысленная работа.

Нет, сначала нужно собрать все пакеты "без задней мысли".  Получится
переходный репозатирий.  Переходный репозитарий = главный репозитарий +
оверлей.  Оверлей -- это типа транзакции, --with-stuff, которая содержит
пакеты, которые будут перемещены/заменены в главном репозитарии.

Далее сравниваем главный и переходный репозитарии по количеству
unmet'ов.  Если в переходном репозитарии есть новые unmet'ы, то пробуем
исключить из оверлея пакеты один за другим, и каждый раз проверяем новые
unmet'ы.  Если при исключении очередного пакета количество unmet'ов
уменьшается, то этот пакет помещается в отстойник, поиск врагов
продолжается на оставшемся оврлее.

> Если же откладывать всех требующих битый пакет, мы можем получить
> некоторый ДОС. Но это жертва на которую я готов пойти. Ведь виновника
> можно очень просто выявить(до пересборки допускаются только
> подписанные пакеты) и дать по мозгу.

Есть два критерия "пакетов, которые требуют битый": 1) жесткий критерий,
то есть версионная зависимость на именно этот битый пакет; 2) мягкий
критерий, в смысле выстраивания очереди на пересборку.

Вопрос: если имеет место быть мягкий критерий, т.е. если группу пакетов
желательно пересобрать с битым, но можно пересобрать и с более ранней
версией битого пакета в главном репозитарии, то что делать?  Если битый
пакет несёт с собой библиотеку с новым soname'ом, то очень плохо.  Но
заранее узнать нельзя.

> > Кстати, я написал/дописал утилиту для *упрощенного* поиска unmet'ов.
> > Казалось бы, куда уж проще, но всё же...
> > 
> > $ ./unmets -s m24-sources.list
> 
> Отлично!
> Я предпочитаю пользоваться простой старой табуреткой: aptbox+diff.

Это и есть wrapper для aptbox, только он переформатирует вывод apt,
чтобы unmet'ы были по одному на строчку.  Такой список уже можно
сортировать или грепать, что немаловажно.  А вместо diff здесь лучше
подходит comm.