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

[Michael Tokarev]

07.05.2022 12:59, Petr Menšík wrote:
> 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.

Yes, that should work.

The only prob is what we do now :)
Especially once some new features are available in libunbound and new software
will try to use UNBOUND_VERSION_* macros to find out if it is available :)

I understand the resistence against rebuilding other software to update
soname, especially in cases like this which could have been avoided easily
(we'd all live much better life if we knew everything beforehand ;) ).
I don't remember how it is on redhat, - on debian we have this done almost
automatically, the transitions from one soname to another. Stuff just being
rebuilt. The probs happen and requires manual intervention if things goes
wrong ofcourse, but in many cases it just works.

It is even possible for upstream unbound to switch from libunbound8 back to
libunbound2 (if it was 2 before, I don't remember already) with this change
in API (not only ABI but also API).

I think we should stay more compatible between each other and upstream. I
really hated it in the past when redhat API was entirely different than
anything else including upstream :)

In debian I know only once piece of software (besides unbound itself) who
use callbacks - this is libreswan.

/mjt