The libhtp SONAME mismatch *is* a policy violation.
control: severity -1 grave
control: block 772551 by -1
control: tag -1 patch
In the current state of the libhtp source package, every new upstream
release of changes the SONAME and thus requires that reverse
dependencies (currently only suricata) are rebuilt. As long as the name
of the binary package stays the same, eventual breakage is guaranteed,
see #772551.
The current state defeats the purpose of shared libraries and violates
section 8.1 ("Run-time shared libraries") of the Debian Policy Manual.
I see three possible solutions:
1. Override upstream's decision to change the SONAME with every release.
I am not entirelysure how stable libhtp's API/ABI should be
considered -- looking at changes and deciding on compatibility issues
making those decisions would certainly put a burden on the maintainer
in the future (although the .symbols mechanism helps for obvious
cases such as removed APIs.)
I am attaching a patch to drop the -release parameter from the
libtool call, libhtp.so.1.0.0 (instead of libhtp-0.5.15.so.1.0.0) is
generated. The .symbols file would need to be updated to reflect that
change, too, of course.
2. Since suricata is the only reverse dependency of libhtp and contains
a copy of libhtp within its source tarball, so we could drop the
libhtp package altogether and use that embedded copy instead, at
least for the jessie release.
3. Change the binary package name to reflect the SONAME -- for instance
libhtp-0.5.15. I believe that we are too late in the freeze to be
adding new binary package names.
Cheers,
-Hilko
--- libhtp-0.5.15.orig/htp/Makefile.am 2015-02-13 21:20:41.518367246 +0100
+++ libhtp-0.5.15/htp/Makefile.am 2015-02-13 21:20:43.622311935 +0100
@@ -25,4 +25,4 @@
lib_LTLIBRARIES = libhtp.la
libhtp_la_SOURCES =
libhtp_la_LIBADD = libhtp-c.la
-libhtp_la_LDFLAGS = -version-info $(GENERIC_LIBRARY_VERSION) -release $(GENERIC_RELEASE)
+libhtp_la_LDFLAGS = -version-info $(GENERIC_LIBRARY_VERSION)
Reply to: