[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Fri, Feb 13, 2015 at 22:13:21 +0100, Hilko Bengen wrote:

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

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


Reply to: