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

[Petr Menšík]

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
b) Modify macros detection to detect the feature presence itself, not by
unbound version

>
> 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 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.
>
> 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 :)
We have a rule 'upstream first' for almost every change we do. If
upstream is willing to make it different way than our proposal, we would
use it that way. If it can satisfy our demands of course. But this
change is compatibility change only. Intended to upgrade unbound daemon
itself, but do not break other dependencies. It would also allow not
shipping unbound-libs 1.7.x and unbound-1.15.x as separate packages
conflicting between themselves.
>
> In debian I know only once piece of software (besides unbound itself) who
> use callbacks - this is libreswan.
>
> /mjt
>
It is different for us in RHEL. We support only part of packages
ourselves. For others we provide building block, but do not have build
or maintain them ourselves. Primary examples are in EPEL repository.
Some other could be private packages of other companies. I think unbound
is a great library and I would like to make it as stable as possible. We
prevent also possible breakages of software not in our distribution.

If someone relies on newer version, there would be RHEL 9 soon for them.
It never had older ABI. But I admit more projects use unbound, but only
libreswan failed to rebuild without the second commit. I guess that
means asynchronous resolution is not very common.

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