On Mon, Jun 19, 2006 at 05:45:43PM +0400, Alexey I. Froloff wrote:
> Если пакет baz зависит от пакета libfoo, получаемого из исходного
> пакета foobar, то пакет baz должен иметь сборочную зависимость на
> пакет bar, тоже получаемый из исходного пакета foobar.  Примем
> это за постулат.

Не обязательно.

> ((note: под это правило не попадают зависимости проставленные
> вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
> и зависимости на модули (python, tcl, но попадает perl). ))
> 
> Пакет foobar, генерирующий libfoo у которого сменился SONAME
> попадает в отстойник с именем FUBAR.  Далее мы имеем список
> FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
> именами исходных пакетов, предоставляющих сборочные зависимости
> для FUBAR-src.
> 
> Для каждого нового пакета генерим список типа FUBAR-req-src и
> если он пересекается с FUBAR-src, то помещаем этот пакет в
> отстойник FUBAR.
> 
> Если этот новый пакет попадает в список FUBAR-req-src, то
> обработка этого пакета блокируется до окончания обработки
> отстойника.
> 
> Если ни то ни другое, пакет обрабатывается как обычно.
> 
> 
> Что я в этой схеме не предусмотрел?  Например когда foo зависит
> от libbar и libbaz, находящихся в разных отстойниках.  Есть
> реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
> "как обычно".
> 
> Под "неувеличением количества unmet'ов" наверно лучше следует
> понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
> не попадает.

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

В общем довольно сложно получается...