[gnutls-devel] symbol and library versioning

[Nikos Mavrogiannopoulos]

On Thu, 2017-08-10 at 14:21 +0200, Andreas Metzler wrote:

> > The versioning that matters is via the linker script, which is then
> > used by packaging software like rpm (I guess possibly dpkg as
> > well),
> > to detect proper dependencies.
> 
> rpm and dpkg work differently here.
> rpm looks at the library at build time and scans it for versioned
> symbol
> definitions. If the library exports GNUTLS_3_4_0 and GNUTLS_3_4_1 the
> resulting library package provides
> libgnutls.so.30
> libgnutls.so.30 (GNUTLS_3_4_0)
> libgnutls.so.30 (GNUTLS_3_4_1)
> 
> And a package linking against gnutls which uses foo at GNUTLS_3_4_1 will
> get a dependency against "libgnutls.so.30 (GNUTLS_3_4_1)".
> 
> Debian works a little bit differently. There is no benefit for dpkg
> based systems in using the fine grained symbol version approach.  The
> gnutls development package comes with a list of exported symbols[1]
> and
> the respective version that a using package needs to depend on:
>  gnutls_idna_reverse_map at GNUTLS_3_4 3.5.9
>  gnutls_init at GNUTLS_3_4 3.5.6
>  gnutls_key_generate at GNUTLS_3_4 3.5.0
> If a binary uses both gnutls_key_generate and gnutls_init it will
> depend
> on gnutls >= 3.5.6 (the maximum of 3.5.6 and 3.5.0).
> There is usually a manual review process involved in updating this
> list
> of symbols. This is evident by the gnutls_init() dependency info.
> gnutls_init was introduced ages ago, however the GNUTLS_NO_TICKETS
> argument was only added in 3.5.6.

Thank you for this nice summary. My target is to have that versioning
suits both systems, and if I understand you correctly despite the
differences in packagers, that's the case.


> > Did I miss something in that? Are there are best practices I
> > missed,
> > or any issues in the rules I set above?
> > Symbol versioning as provided by libgnutls.map have several
> > advantages.
> >   1 they allow for symbol clashing between different gnutls library
> >     versions being in the same address space.
> >   2 they allow installers to detect the library version used for an
> >     application utilizing a specific symbol
> >   3 the allow introducing multiple versions of a symbol a la libc,
> >     keeping the semantics of old functions while introducing new.
> 
> 1 is what GnuTLS symbol-versioning in released versions (all symbols
> versioned with a unified sonamed-specific label) currently
> accomplishes.
> 2 seems to be what you are aiming for, enhancing RedHat's package
> dependencies.

Right.

> 3 Is this a goal you are envisioning of following? If not it would
> clear
> things up to clearly state that GnuTLS is not (currently) using
> symbol
> versioning for this purpose.

Nice question. I was thinking to use that feature as tool to prevent
breaking ABI on cases where compatibility could be kept relatively
easily, or when the enhancement of a function would break all previous
callers, rather than strive keep a 100% backwards compatibility on
bugs.

> (On a sidenote: Is there anybody except
> glibc doing this?)

I'm not aware of other projects using that to the level of glibc.

> I think there is typo in the following text, the numbers seem to be
> off.
> s/GNUTLS_3_6_2/GNUTLS_3_6_3/

Thanks. It should be addressed now.

> > As such for every symbol introduced on a particular version, we
> > create
> > an entry in libgnutls.map based on the version and containing the
> > new
> > symbols. For example, if in version 3.6.3 we introduce symbol
> > gnutls_xyz, the entry would be:
> > 
> > GNUTLS_3_6_2 { global: gnutls_xyz; } GNUTLS_3_6_1;
> > 
> > where GNUTLS_3_6_1 is the last version that symbols were
> > introduced, and
> > indicates a dependency of 3.6.2 to symbols of 3.6.1.
> 
> This has not been a problem with the old approach. 

Do you refer to the text above or the backporting issue?

regards,
Nikos

> > > >