>> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из
>> Космоса, верно? А моё предположение, что люди тут понимают: сначала на
>> базе спека собирается пакет, при установке которого заполняется база -- оно
>> слишком опрометчиво оказалось.
> Вы, наверное, плохо представляете объем зависимостей, которые создает rpm автоматически
> (find-requires и другие механизмы, в т.ч. для вытягивание зависимостей из результатов
> линковки для нативного кода, из анализа метаданных с описанием зависимостей для
> разных языков типа maven-файлов для java и т.п.). В requires в
> спеке они явно вписаны могут не быть (хорошо это или плохо
> - другой вопрос). А в rpmdb они будут.

Автоматически пусть хоть в Небесную Канцелярию звонят. Начинается всё с создаваемого методом тыка спека. Вот когда автоматически начнут создавать spec, и пересборка пакетиков не будет превращаться в Китайский Новый год, когда никаких обновлений нет, тогда у меня вопросы отпадут.

> Более того, в гайдлайнах есть явные требования не писать всякую очевидную чепуху
> в явные зависимости спека, типа glibc. При сборке она все равно
> будет в наличии, а в итоговом пакете эта зависимость будет вписана
> автогенератором.

Знаю. Читал жалобы пользователей той же Росы, как urpmi --auto-orphans превращает систему в тыкву.

>>>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
>>> и граф надо строить заново. Что не так?
>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только
>> лишь библиотек.
> Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать?

Практика показала, что перед тем как дёрнуть, функция там должна присутствовать.

> Это проблема линковщика,
> а на уровне пакетов достаточно зависимости уровня библиотек.