Do we need to bump the shared library version for 2.4.0?

[Simon Josefsson]

In 2.3.x we have moved several symbols from libgnutls-extra to libgnutls
(see complete explanation in the 2.4.0 release notes draft below), but
do we need to bump the shared library version?  No symbols have been
removed from any library libgnutls*, except for the symbols that have
been moved.  libgnutls-extra links to libgnutls.

I see several solutions here:

1) Increment the shared library version of libgnutls*.

   This will cause an unnecessary shared library version break for
   libgnutls, which have only had new functions added to it.  Given the
   problem described in 2) I'm not sure how it could be avoided though.

2) Separate the shared library versions for libgnutls and
   libgnutls-extra, and increment only the libgnutls-extra version.

   This may be the The Right Thing to do, but it causes a new problem:
   an application linking to libgnutls-extra.so.26 (2.2.x) may pull in
   libgnutls.so from 2.4.x, which won't work together.  Both
   libgnutls.so and libgnutls-extra.so would then provide the same
   symbols.  If the application uses the one from libgnutls.so all is
   fine, but it will break of the ones from libgnutls-extra.so is used.

3) Don't increment the shared library version at all.

   The justification would be that we haven't removed any symbols, all
   symbols in libgnutls-extra are still available via libgnutls and work
   the same way.  The only thing that would break here is if someone is
   dlopen'ing libgnutls-extra.so and calls the openpgp related
   functions.  Strictly speaking I'm not sure this is a valid approach,
   since we HAVE removed symbols from libgnutls-extra.

Thoughts?

I'm leaning towards 1) because of the problem in 2) and 3), however I do
realize this will generate a lot of work for our packagers.

Thanks,
Simon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls23.txt
URL: </pipermail/attachments/20080526/38a83b3a/attachment.txt>