Re: The libhtp SONAME mismatch *is* a policy violation.

[Hilko Bengen <bengen@debian.org>]

* Julien Cristau:

>> 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.
>> 
> For jessie, 2 sounds like the best way to go IMO.

Thank you. Could somebody please decide about #777042 ("unblock:
suricata/2.0.6-1")?

A positive answer, together with the decision to use the copy of the
libhtp sources shipped as part of suricata for jessie, would also take
care of #777040 ("unblock: libhtp/0.5.16-1"), as well as security issues
#774897, #777522, and #777523.

Cheers,
-Hilko