Maintained by: NLnet Labs

[Unbound-users] [NLnet Labs Maintainers] unbound-1.2.1 released

Ondřej Surý
Thu Feb 12 13:35:19 CET 2009


I checked man page of libunbound and it seems to me that there are many
internal symbols in libunbound (since public interface is only ub_*).

Perhaps you need to split library in two?  So libunbound exports only
public interface as documented in libunbound(3)?  That way you can
have libunbound-private (or something like that) where you could
increase SONAME each time you remove symbol and it will not hit
other binaries linked against libunbound.  Other way is to bump
soname when you remove symbols (ie. backwards compatibility).

I know it's pain in the ass - but now nobody can stop third party
from using internal symbols from this library and there third party
programs would break when you change API/ABI.

P.S.:  Some notes from dpkg-gensymbols:
   Using wildcards with versioned symbols
       Well  maintained  libraries have versioned symbols where each
version corresponds to the upstream version where the symbol got
added. If that’s the
       case, it’s possible to write a symbols file with wildcard
entries like "*@GLIBC_2.0"  that  would  match  any  symbol
associated  to  the  version
       GLIBC_2.0. It’s still possible to include specific symbols in
the file, they’ll take precedence over any matching wildcard entry. An
example: libc6 #MINVER#
        *@GLIBC_2.0 2.0
        *@GLIBC_2.7 2.7
        access at GLIBC_2.0 2.2

       The  symbol access at GLIBC_2.0 will lead to a minimal dependency
on libc6 version 2.2 despite the wildcard entry *@GLIBC_2.0 which
associates symbols
       versioned as GLIBC_2.0 with the minimal version 2.0.

       Note that using wildcards means that dpkg-gensymbols can’t
check for symbols that might have disappeared and can’t  generate  a
diff  between  the
       maintainer-supplied symbols file and the generated one in the
binary package.

   Good library management
       A well-maintained library has the following features:

       ·   its  API  is stable (public symbols are never dropped, only
new public symbols are added) and changes in incompatible ways only
when the SONAME

       ·   ideally, it uses symbol versioning to achieve ABI stability
despite internal changes and API extension;

       ·   it doesn’t export private symbols.

       While maintaining the symbols file, it’s easy to notice
appearance and disappearance of symbols. But it’s more difficult to
catch incompatible  API
       and ABI change. Thus the maintainer should read thoroughly the
upstream changelog looking for cases where the rules of good library
management have
       been broken. If potential problems are discovered, the upstream
author should be notified as an upstream fix is always better than  a
Debian  spe‐
       cific work-around.



On Thu, Feb 12, 2009 at 12:08 PM, Ondřej Surý <ondrej at> wrote:
> Wouter,
> libunbound0 is missing these symbols:
> +#MISSING: 1.2.1# acl_list_cmp at Base 1.0.0
> +#MISSING: 1.2.1# libworker_handle_result_write at Base 1.0.0
> +#MISSING: 1.2.1# libworker_read_msg at Base 1.0.0
> +#MISSING: 1.2.1# libworker_write_msg at Base 1.0.0
> +#MISSING: 1.2.1# stub_cmp at Base 1.0.0
> Either you need to reintroduce them or bump SONAME to libunbound1.  Please
> be careful when removing symbols from library - update like this could make
> third party application to stop working.
> Ondrej.
> On Tue, Feb 10, 2009 at 9:01 AM, W.C.A. Wijngaards <wouter at> wrote:
>> Hash: SHA1
>> Hi,
>> This is the release of unbound 1.2.1
>> It works with ldns-1.5.0, also just released.
>> Get it at
>> SHA1 996aea210b24f8c4bd1aa7a9584bc5b70b989b1b
>> SHA256 1f95ca2904dfb813bf52f15156a8c769b365deb92fa7b995344062dea966dc29
>> (or use if our mirror has not updated yet).
>> The rc1 tarball has not changed, apart from the version number.
>> Best regards,
>>   Wouter
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Fedora -
>> iEYEARECAAYFAkmRNG4ACgkQkDLqNwOhpPhJtgCePAbyBECmc55ou8jLXXqm67hy
>> XKEAnRn9ySYPRDGSS8MAb9Jwh71Hnd96
>> =0Tio
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Maintainers mailing list
>> Maintainers at
> --
> Ondřej Surý <ondrej at>

Ondřej Surý <ondrej at>