>[оверквотинг удален]
> никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/*
> данные, они собирают их самостоятельно, после сборки программы и перед ее
> упаковкой в архив.
> Никакой особой магии нет, используется компот из ldd, grep (не все зависимости
> у нас разрешает ld - есть еще интерпретируемые языки) и
> так далее. Его поведением можно управлять, но обычно не нужно.
> Вот результат всего этого - он, естественно, разный при малейших изменениях сборочной
> среды - и попадает потом из пакета в rpmdb (для графа
> нам, естественно, нужна именно она, а не отдельный пакет, поскольку мы
> хотим видеть зависимости зависимостей).Это всё несущественные мелочи и детали реализации.
>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
>> библиотек.
> это слишком геморройно
И чего такого в ELF принципиально отличного от PE (для которого приходилось решать сходную задачу, при том что нужный функционал из ldd пришлось реализовать самому)?
> (и не поможет для пакета использующего 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, но это немодно
> и немолодежно.
И этот же автор пишет ниже про Gentoo portage...
