как я проверяю, если (вручную) обновление программного обеспечения повредит существующее программное обеспечение?

Совместимость на уровне двоичных кодов - ABIs и API

Для понимания, почему создание обновлений может или не может повредить существующее программное обеспечение на машине у Вас должна быть неопределенная осведомленность о ABIs и API библиотек. Посмотрите этот связанный вопрос на StackOverflow для большего количества информации.

Общее управление версиями библиотеки

Программное обеспечение обычно выпускается, по крайней мере, с номерами основной версии и номерами вспомогательной версии. Я считал, что обычно, любые несовместимости ABI должны только быть представлены наряду с изменением в номере основной версии. Таким образом, если Вы обновляете между вспомогательными версиями, необходимо обычно быть в безопасности просто установить новую версию по старому.

Установленным совместно использованным библиотекам нужно добавить номер версии к имени файла, и часто это отличается от номера релизной версии. Другие приложения в зависимости от той общей библиотеки будут связаны в при создании исходного кода. Получающийся двоичный файл должен затем использовать динамического компоновщика для поиска совместно использованной библиотеки права, определил его ее номером основной версии. (Это, вероятно, зависит от используемого компоновщика и существует, вероятно, ld опция, которая позволяет Вам указывать вспомогательную версию вместо этого..)

libsqlite3

Используя libsqlite3-0 (3.7.13-1) как пример, у меня есть совместно использованный файл библиотеки того и две символьных ссылки, указывающие на ту библиотеку:

> ls -l /usr/lib/x86_64-linux-gnu/libsqlite3.so*
lrwxrwxrwx 1 root root     19 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root     19 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rw-r--r-- 1 root root 692984 Jun 14 14:05 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6

Так, как сказать, были ли библиотека или исполняемый файл связаны против этой библиотеки, и от какой версии она зависит?

На Linux используйте:

`ldd <filename>`

На OS X:

`otool -L <filename>`

Например, давайте посмотрим что версия sqlite потребностей модуля libsqlite3 Python, давайте функционировать.

> ldd /usr/lib/python2.7/lib-dynload/_sqlite3.so | grep sqlite
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fe32872c000)

Таким образом, этому только нужна основная версия, пронумеровал символьную ссылку, а не полностью именованный и перечислил совместно использованную библиотеку. Обновления затем, должен просто обновить символьные ссылки libsqlite3.so [.0] для указания на новую общую библиотеку.

Создание ультрасовременного libsqlite из источника, надо надеяться, создало бы общую библиотеку с тем же номером основной версии. В противном случае можно всегда перезаписывать символьную ссылку и указывать на него на требуемую версию, тестировать и возвращаться к системным пакетам, если/когда необходимо.

Способность

Поскольку Вы используете Debian, я думал, что также упомяну это aptitude позволяет Вам представлению "Packages which depend on libsqlite3-0 (267)" (и то же для любого другого пакета, также). Конечно, если Вы скомпилировали много приложений из источника и не сообщили dpkg из этого затем этот список не может быть исчерпывающим.

Посмотрите отчет об обратной бинарной совместимости для библиотеки здесь (или может быть здесь). Не стоит обновляться, если в библиотеке есть некоторые ABI-разрывы между сравниваемыми версиями.

Также ваша конфигурация библиотеки может отличаться от дистрибутивной (некоторые специфические опции, которые могут вызвать некоторые изменения в ABI), поэтому лучше обновлять библиотеки только с помощью менеджера пакетов.

В частности, обновление sqlite выглядит безопасным из-за этого отчета: