> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из Космоса, верно?

проще: они туда попадают не из спека.
Точнее, в редких-редких случаях - и из спека тоже.

> А моё предположение, что люди тут понимают: сначала на базе спека собирается пакет, при установке
> которого заполняется база

нет, не при установке. При сборке. Вы просто не в курсе довольно банальных особенностей технологии.

никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/* данные, они собирают их самостоятельно, после сборки программы и перед ее упаковкой в архив.
Никакой особой магии нет, используется компот из ldd, grep (не все зависимости у нас  разрешает ld - есть еще интерпретируемые языки) и так далее. Его поведением можно управлять, но обычно не нужно.

Вот результат всего этого - он, естественно, разный при малейших изменениях сборочной среды - и попадает потом из пакета в rpmdb (для графа нам, естественно, нужна именно она, а не отдельный пакет, поскольку мы хотим видеть зависимости зависимостей).

> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
> библиотек.

это слишком геморройно (и не поможет для пакета использующего numpy ;-) но у библиотек есть versioning:
libcrypt.so.1(GLIBC_2.2.5)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.10)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
и так далее. Как видите, некоторые базовые меры предосторожности предпринимаются, хотя по задумке должно было хватать цифирок после .so, но это немодно и немолодежно.