Rather than squashing the bad .la deps in debian/rules at install time
I think it's better to squash them right after the .la files
themselves are created - that, plus some adjustment in the use of
$(TLIBS), makes dpkg-shlibdeps much happier about unnecessary direct
dependencies of libtclsqlite3.so and the sqlite3 binary. This patch
does that. (There are still some dpkg-shlibdeps complaints but they
have to do with libicu*, so that's entirely fixable within
debian/rules.)
This is not upstreamable as it will break static linkage. I'm not
sure if libtool *can* do static linkage correctly, and with upstream's
pathetic excuse for a configure script I don't think it's feasible
even if libtool itself could get it right.
zw
--- sqlite3-3.6.11.orig/Makefile.in 2009-03-24 11:40:55.000000000 -0700
+++ sqlite3-3.6.11/Makefile.in 2009-03-24 11:42:36.000000000 -0700
@@ -463,18 +463,20 @@
libsqlite3.la: $(LIBOBJ)
$(LTLINK) -o $@ $(LIBOBJ) $(TLIBS) \
${ALLOWRELEASE} -rpath "$(libdir)" -version-info "8:6:8"
+ sed -i "/dependency_libs/s/'.*'/''/" $@
libtclsqlite3.la: tclsqlite.lo libsqlite3.la
$(LTLINK) -o $@ tclsqlite.lo \
- libsqlite3.la @TCL_STUB_LIB_SPEC@ $(TLIBS) \
+ libsqlite3.la @TCL_STUB_LIB_SPEC@ \
-rpath "$(TCLLIBDIR)" \
-version-info "8:6:8" \
-avoid-version
+ sed -i "/dependency_libs/s/'.*'/''/" $@
sqlite3$(TEXE): $(TOP)/src/shell.c libsqlite3.la sqlite3.h
$(LTLINK) $(READLINE_FLAGS) \
-o $@ $(TOP)/src/shell.c libsqlite3.la \
- $(LIBREADLINE) $(TLIBS) -rpath "$(libdir)"
+ $(LIBREADLINE) -rpath "$(libdir)"
# This target creates a directory named "tsrc" and fills it with
# copies of all of the C source code and header files needed to
