On Thu, Aug 23, 2007 at 02:52:25PM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2007 at 02:18:40PM +0300, Mykola S. Grechukh wrote:
> > простейший пример - если пакетов qnetwalk поставить
> > Provides: kdelibs
> > Obsoletes: kdelibs
> > 
> > .. то старые списки покажут, что его никто не использует.
> > А на самом деле разломается сборка всего кдешного.
> 
> Я же написал -- "80%".  Инженер по качеству и полицейский с
> дубинкой -- немного разные роли, даже если и пересекающиеся.
> 
> С такими аргументами... от rm -rf в %post тоже никаких страховок
> нет, и по существу быть не может.

Это другая проблема.  Я сделал постановку задачи для своей пробемы.
Она примерно такая.  В сизиф собрался новый бинарный пакет (или
несколько пакетов из одного src.rpm пакета).  Теперь для каждого
src.rpm пакета нужно КАК БЫ инициализировать сборочный билдрут
и посмотреть, не встал ли в какой из этих билдрутов один из вновь
пришедших пакетов.  Если в билдрут для сборки src.rpm пакета встаёт
один из пришедших пакетов, то этот src.rpm пакет нужно тестировать
пересборкой.

(Соответственно, я играю в "игру" в рамках этой постновки задачи.
В других задачах будут другие подходы.  Они тоже есть.  legion
когда-то пытался сделать установку+удаление пакета и последующую
проверку чрута через osec.  Это надо будет со временем возродить,
или хотя бы понять, что там не склеилось.)

Всё дело, конечно, в том, что означает "КАК БЫ".  Реально
инициализировать билдрут для каждого src.rpm пакета это никаких
ресурсов не хватит.  Просто делать apt-get --print-uris, не доходя
до установки пакетов в билдрут, это порядка одной секунды на src.rpm
пакет.  Я сейчас утверждаю, что есть способ получить аутентичный
результат в 5 раз быстрее.

То что ты предлагаешь я делал 2 года назад.  Для каждого src.rpm пакета
хранится список пакетов билдрута от предыдущей его сборки.  То есть
таблица <pkg-name> <rpm-file-basename>.  (На самом деле достаточно
хранить только rpm-file-basename, потому что отрезанием
-version-release-*.rpm получается pkg-name).  Теперь достаточно
"гнепнуть" (join'ом) старые списки на предмет совпадения pkg-name
относительно прибывших пакетов.

Это не только не решает Provides+Obsolets, это не решает даже
виртуальных зависимостей.  Например пришёл пакет libstdc++4.2-devel.
Его в предыдущих списках нигде нет.  Значит, наша система "не
догадается" пересобрать приплюснутые пакеты.  Такое простое
опровержение <...>