Version 1.15.0 compatible with libunbound.so.2, is it good idea?

[Petr Menšík]

Ah, true. I have hit this with libreswan package in copr. Made another
change, which should solve this. I fake version definitions in unbound.h
to 1.7.x, where x is concatenated real major and minor version. That
should work with most of source codes.

When I tried recompilation at copr
(https://copr.fedorainfracloud.org/coprs/pemensik/unbound/builds/), only
libreswan failed before. I hope this change would make it transparent
for it.

Check out this addition:
https://github.com/InfrastructureServices/unbound/commit/4e66707e8ce18c7f7b8e4ed954b7298c830eea40

I think it could work well.

On 5/6/22 22:07, Michael Tokarev wrote:
> 06.05.2022 21:55, Petr Menšík via Unbound-users wrote:
> ...
>> I have already found libreswan does not expect such change and would not
>> build with such version. Do you know about other users of unbound
>> library, which might be affected? Do you know about any other attempt to
>> keep ABI but update bugs or features? Has any other distribution solved
>> such problem?
>
> It looks like by now, (some) users of libunbound already expect the new
> interface with extra parameter (maybe with an ifdef based on version),
> and this change will break it on source level.
>
> In debian we have everything building with the new API for quite some
> time, --
> many packages use libunbound8 these days.
>
> /mjt
>
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB