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

[Petr Menšík]

On 5/9/22 13:44, Paul Wouters wrote:
>> On May 9, 2022, at 05:33, Petr Menšík via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
>>
>> On 5/8/22 12:28, Michael Tokarev wrote:
>>> 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 :)
>> When someone needs new features of libunbound, he has two choices
>>
>> a) Detect RHEL8 compatibility macros and use UNBOUD_VERSION_MINOR_REAL
> Please ensure a simple define is present, preferably with REDHAT in the name ?

would UNBOUND_VERSION_MINOR_REDHAT work better? Or should I define something like UNBOUND_REDHAT_CALLBACK? I am not sure

>
>> b) Modify macros detection to detect the feature presence itself, not by
>> unbound version
> Please don’t assume autoconf. Without autoconf, detecting outside of ifdef’s is really hard and hacky.
>
> Paul
>
It is still reasonably simple even with cmake. Do you have any specific
build environment on mind? It only compilation tests are used, it would
work fine even when cross compiling. But I admit I don't know simple
test for callback, which would fail with error. Not only with warning.
>>> IIt would not be a problem on Fedora. We can rebuild dependencies too.
>> But RHEL is stable distribution not only for its own packages. We
>> provide API and ABI even for any customer's projects. If they would use
>> unbound for anything, they would have to rebuild in minor release and
>> support one version before and one version after. That is what I would
>> like to prevent.
> Package old as libunboundXX, similar to like bind8/bind(9) in the past?
>
> Paul

The thing is unbound-libs package contains also unbound-anchor.service,
which uses unbound-anchor to keep /var/lib/unbound/root.key up-to-date
automagically even if the key changes. Shipping another library package
would be possible, but it would have to solve conflict of those services
and who should maintain that key validity. It gets unnecessary complicated.

I think suggested changes make it simple enough and backward compatible
while adding just self-contained changes.

But all packages I checked on Fedora do not use ub_resolve_event
function with just one exception: libreswan. It seems no one else
adopted asynchronous callback.

I have just verified it still passes ratelimit test, even after my change.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB