Useless libtr_tid dependencies

[Jennifer Richards]

The Debian package build system reports that the libtr-tid2 package is linked against libraries whose symbols it does not use. I believe this is correct and these could be removed.

  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libtr-tid2/usr/lib/x86_64-linux-gnu/libtr_tid.so.2.2.0 was not linked against libsqlite3.so.0 (it uses none of the library's symbols)
  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libtr-tid2/usr/lib/x86_64-linux-gnu/libtr_tid.so.2.2.0 was not linked against libevent-2.0.so.5 (it uses none of the library's symbols)

[Sam Hartman (hartmans)]

I'd recommend balancing minimizing dependencies against complicating the
build system.

In general, minimizing dependencies only has significant value if you
can minimize package-level dependencies. So, for example, if you can
avoid all the libraries in the libtr-tid package depending on sqlite3,
then you can simplify upgrades and upgrade ordering.
However if one shared library in libtr-tid depends on sqlite3 and
another does not, you don't tend to gain much in most situations.

In contrast, managing dependencies generated by autoconf or pkg-config
on a per-library basis is a bit annoying and does add some complexity to
the build system.

I've picked sqlite3 as an example because I actually suspect that you
can avoid everything but tids linking against sqlite3 and so that
dependency may well be worth removing.
Some of the others less so.

--Sam

[Jennifer Richards (jennifer-k)]

I think the library is free of both libevent2 and libsqlite3. The former it certainly should be, it's just a question of whether libevent2 crept outside of the trust router code where I intended to confine it.

Whether it's worth the complexity / effort is a good question, especially since neither of those is a terribly onerous requirement.