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