Binary compatibility - ABIs and APIs
To understand why making updates may or may not break existing software on your machine, you should have a vague awareness of libraries' ABIs and APIs. See this related question on StackOverflow for more info.
Shared library versioning
Software is usually released with at least major and minor version numbers. I have read that generally, any ABI incompatibilities should only be introduced along with a change in major version number. So if you're upgrading between minor versions, you should generally be safe to just install the new version over the old.
Installed shared libraries should have a version number appended to the file name, and often this differs from the release version number. Other applications depending on that shared library will have been linked in when building the source code. The resulting binary should then use the dynamic linker to look for the right shared library, identified it by its major version number. (This is probably dependent on the linker used and there's probably an
ld option, which allows you to specify minor version instead..)
Using libsqlite3-0 (3.7.13-1) as an example, I have one shared library file and two symbolic links pointing to that library:
> 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
So, how to tell if a library or executable has been linked against this library, and what version it depends on?
On Linux, use:
On OS X:
`otool -L <filename>`
For example, let's see what version of libsqlite3 Python's sqlite module needs, to function.
> ldd /usr/lib/python2.7/lib-dynload/_sqlite3.so | grep sqlite
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fe32872c000)
So it only needs the major-version numbered symbolic link, and not the fully named and numbered shared library. Updates then, should just update the libsqlite3.so[.0] symbolic links to point to the new shared library.
Building a cutting-edge libsqlite from source would hopefully create a shared library with the same major version number. If not, you can always overwrite the symbolic link and point it to your desired version, test, and revert to system packages if/when necessary.
As you're using Debian, I thought I'd also mention that
aptitude allows you to view "Packages which depend on libsqlite3-0 (267)" (and the same for any other package, too). Of course, if you've compiled a lot of applications from source, and haven't informed
dpkg of this, then this list may not be exhaustive.