[gnutls-dev] gnutls versioning again

[Dmitry V. Levin]

Hi,

On Sun, Feb 04, 2007 at 12:59:05PM +0100, Simon Josefsson wrote:
> I'm copying the list on this, since I'd appreciate wider discussion.
> 
> Pavlov Konstantin writes:
> 
> > Another problem i recognized is the lack of real symbol versioning in 
> > libgnutls:
> > GNUTLS_1_3
> > {
> >   global: _gnutls*; gnutls*; _E_*;
> >   local: *;
> > };
> >
> > I made a new .version file for 1.6.1 release, it looks like :
> > GNUTLS_1_3
> > {
> >   global: _gnutls*; gnutls*; _E_*;
> > };
> >
> > GNUTLS_1_6_1 {
> >     global:
> >         gnutls_transport_set_errno;
> >         gnutls_transport_set_global_errno;
> >         local:  *;
> > };
> >
> >
> > What do you think about it ?
> 
> I've re-read the relevant parts of Drepper's DSO howto to refresh my
> memory on this, but still, I don't see what problem the above change
> would fix.  Could you explain?
> 
> The only problem that I can think of that the above would solve if is
> an application that uses e.g. gnutls_transport_set_errno was built
> against 1.6.x or later is moved to a system which has an older
> libgnutls installed that doesn't have that symbol.  The application
> will not work.

Yes.  Imagine large binary package repository (e.g. Debian or Sisyphus).
Maintainer builds new software which uses new symbols from gnutls.
When user installs package with this new software, there are no indication
that it requires new version of gnutls, so old version of gnutls may
remain unupgraded.  As result, user will see runtime relocation error
which is not what maintainer usually want.

To resolve this issue, our gnutls package maintainer had to create new
interface, e.g. GNUTLS_1_6_1 and place new symbols there.  As result,
every package with software which uses these symbols will automatically
have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1),
so any user installing this package will also update gnutls package.

> We can't protect against that, though, as far as I can see.  If an
> application uses a new interface, he must make sure a library that
> implements that interface is available.

Just otherwise, library should provide new symbols via new interface,
so an application which uses new symbols will get necessary dependencies.

> Thus, my conclusion would be that, generally, adding new interface
> doesn't require changes to the version script.

If new version of a library exports new symbols, it should add new
interface explicitly, using version script or any other available method.
As I see, gnutls uses version script for this purposes.

> All this said, I'm not an expert on DSO versioning, so I'd appreciate
> comments on the reasoning in this post.

No problem.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070215/c3ddd083/attachment.pgp